+If you want to test this POST HTTP request, you can use any HTTP client such as [Microsoft PowerShell](/powershell/scripting/overview).

+Now that you've acquired an authorization code, you can redeem the `code` for a token to the intended resource by sending a POST request to the `/token` endpoint. In Azure AD B2C, you can [request access tokens for other APIs](access-tokens.md#request-a-token) as usual by specifying their scope(s) in the request.

+If you're testing this POST HTTP request, you can use any HTTP client such as [Microsoft PowerShell](/powershell/scripting/overview).

+ 1. To make a POST request similar to the one shown in this example, you can use an HTTP client such as [Microsoft PowerShell](/powershell/scripting/overview).

+For your custom policy to reach your Node.js app, it needs to be reachable, so, you need to deploy it. In this article, you deploy the app by using [Azure App Service](../app-service/overview-vnet-integration.md), but you use an alternative hosting approach.

+You can test the app you've deployed by using an HTTP client such as [Microsoft PowerShell](/powershell/scripting/overview). This time, use `https://custompolicyapi.azurewebsites.net/validate-accesscode` URL as the endpoint.

+## March 2024

+### Well-Architected Framework (WAF) assessments & recommendations

+The Well-Architected Framework (WAF) assessment provides a curated view of a workloadΓÇÖs architecture. Now you can take the WAF assessment and manage recommendations on Azure Advisor to improve resiliency, security, cost, operational excellence, and performance efficiency. As a part of this release, we're announcing two key WAF assessments - [Mission Critical | Well-Architected Review](/assessments/23513bdb-e8a2-4f0b-8b6b-191ee1f52d34/) and [Azure Well-Architected Review](/assessments/azure-architecture-review/).

+To get started, visit [Use Azure WAF assessments](/azure/advisor/advisor-assessments).

+**This content applies to:**  **v3.0 (GA)** | **Latest versions:**  [**v4.0 (preview)**](?view=doc-intel-4.0.0&preserve-view=true)  [**v3.1**](?view=doc-intel-3.1.0&preserve-view=true)

+**This content applies to:**  **v3.0 (GA)** | **Latest versions:**  [**v4.0 (preview)**](?view=doc-intel-4.0.0&preserve-view=true)  [**v3.1**](?view=doc-intel-3.1.0&preserve-view=true)

+**This content applies to:**  **v3.0 (GA)** | **Latest versions:**  [**v4.0 (preview)**](?view=doc-intel-4.0.0&preserve-view=true)  [**v3.1**](?view=doc-intel-3.1.0&preserve-view=true)

+**This content applies to:**  **v3.0 (GA)** | **Latest versions:**  [**v4.0 (preview)**](?view=doc-intel-4.0.0&preserve-view=true)  [**v3.1**](?view=doc-intel-3.1.0&preserve-view=true)

+**This content applies to:**  **v3.0 (GA)** | **Latest versions:**  [**v4.0 (preview)**](?view=doc-intel-4.0.0&preserve-view=true)  [**v3.1**](?view=doc-intel-3.1.0&preserve-view=true)

+**This content applies to:**  **v3.0 (GA)** | **Latest versions:**  [**v4.0 (preview)**](?view=doc-intel-4.0.0&preserve-view=true)  [**v3.1**](?view=doc-intel-3.1.0&preserve-view=true)

+**This content applies to:**  **v3.0 (GA)** | **Latest versions:**  [**v4.0 (preview)**](?view=doc-intel-4.0.0&preserve-view=true)  [**v3.1**](?view=doc-intel-3.1.0&preserve-view=true)

+ Title: "Use Document Intelligence client library or REST API "

+description: Learn how to use Document Intelligence client libraries or REST API and create apps to extract key data from documents.

+In this guide, learn how to add Document Intelligence models to your applications and workflows. Use a programming language SDK of your choice or the REST API.

+Choose from the following Document Intelligence models and analyze and extract data and values from forms and documents:

+> - The [prebuilt-read](../concept-read.md) model is at the core of all Document Intelligence models and can detect lines, words, locations, and languages. Layout, general document, prebuilt, and custom models all use the `read` model as a foundation for extracting texts from documents.

+> - The [prebuilt tax document models](../concept-tax-document.md) model extracts information reported on US tax forms.

+> - The [prebuilt-idDocument](../concept-id-document.md) model extracts key information from US drivers licenses, international passport biographical pages, US state IDs, social security cards, and permanent resident cards.

+> [!div class="checklist"]

+>

+> - The [prebuilt-businessCard](../concept-business-card.md) model extracts key information and contact details from business card images.

+Congratulations! You learned to use Document Intelligence models to analyze various documents in different ways. Next, explore the Document Intelligence Studio and reference documentation.

+> [Try the Document Intelligence Studio](https://formrecognizer.appliedai.azure.com/studio) [Explore the Document Intelligence REST API](/rest/api/aiservices/document-models/analyze-document?view=rest-aiservices-2023-07-31&preserve-view=true&tabs=HTTP)

+* For an enhanced experience and advanced model quality, try [**Document Intelligence Studio**](https://formrecognizer.appliedai.azure.com/studio)

+* For v3.1 to v4.0 migration, see [**Changelog Migration guides**](../changelog-release-history.md#march-2024-preview-release).

+description: In this quickstart, learn to use the Document Intelligence Sample Labeling tool to manually label documents. Then train a custom document processing model with the labeled documents and use the model to extract key/value pairs.

+You need the following to get started:

+Document Intelligence offers several prebuilt models to choose from. Each model has its own set of supported fields. The model to use for the `Analyze` operation depends on the type of document to be analyzed. Here are the prebuilt models currently supported by the Document Intelligence service:

+1. Select **Run analysis**. The Document Intelligence Sample Labeling tool calls the Analyze Prebuilt API and analyze the document.

+1. View the results - see the key-value pairs extracted, line items, highlighted text extracted, and tables detected.

+ * The "selectionMarks" node shows every selection mark (checkbox, radio mark) and whether its status is `selected` or `unselected`.

+1. Select **Run Layout**. The Document Intelligence Sample Labeling tool calls the `Analyze Layout API` and analyzes the document.

+ :::image type="content" source="../media/fott-layout.png" alt-text="Screenshot of layout dropdown menu.":::

+1. View the results - see the highlighted text extracted, selection marks detected, and tables detected.

+Train a custom model to analyze and extract data from forms and documents specific to your business. The API is a machine-learning program trained to recognize form fields within your distinct content and extract key-value pairs and table data. You need at least five examples of the same form type to get started and your custom model can be trained with or without labeled datasets.

+ [CORS (Cross Origin Resource Sharing)](/rest/api/storageservices/cross-origin-resource-sharing--cors--support-for-the-azure-storage-services) needs to be configured on your Azure storage account for it to be accessible from the Document Intelligence Studio. To configure CORS in the Azure portal, you need access to the CORS tab of your storage account.

+ 1. Select the save button at the top of the page and save the changes.

+1. **Security Token**. Each project autogenerates a security token that can be used to encrypt/decrypt sensitive project settings. You can find security tokens in the Application Settings by selecting the gear icon at the bottom of the left navigation bar.

+1. **Folder Path** (optional). If your source forms are located within a folder in the blob container, specify the folder name.

+Select **Run Layout on unvisited documents** on the left pane to get the text and table layout information for each document. The labeling tool draws bounding boxes around each text element.

+The labeling tool also shows which tables were automatically extracted. Select the table/grid icon on the left hand of the document and see the extracted table. Because the table content is automatically extracted, we don't label the table content, but rather rely on the automated extraction.

+Next, you create tags (labels) and apply them to the text elements that you want the model to analyze. Note the Sample Label data set includes already labeled fields; we add another field.

+Choose the Train icon on the left pane and open the Training page. Then select the **Train** button to begin training the model. Once the training process completes, you see the following information:

+* **Model ID** - The ID of the model that was created and trained. Each training call creates a new model with its own ID. Copy this string to a secure location; you need it if you want to do prediction calls through the [REST API](./get-started-sdks-rest-api.md?pivots=programming-language-rest-api) or [client library](./get-started-sdks-rest-api.md).

+1. Select the **`Analyze`** icon from the navigation bar and test your model.

+1. Choose the **Run analysis** button to get key/value pairs, text, and tables predictions for the form. The tool applies tags in bounding boxes and reports the confidence of each tag.

+That's it! You learned how to use the Document Intelligence sample tool for Document Intelligence prebuilt, layout, and custom models. You also learned to analyze a custom form with manually labeled data.

+This article is to help you understand the support lifecycle for the Azure OpenAI API previews. New preview APIs target a monthly release cadence. After July 1, 2024, the latest three preview APIs will remain supported while older APIs will no longer be supported unless support is explictly indicated.

+ api_version = '2024-03-01-preview' # this may change in the future

+Text prompts are how users interact with GPT models. As with all generative language models, GPT models attempt to produce the next series of words that are most likely to follow from the previous text. It's as if we're saying *What is the first thing that comes to your mind when I say `<prompt>`?*. The examples below demonstrate this behavior. Given the first words of famous content, the model is able to accurately continue the text.

+Primary content refers to some sort of text that is being processed or transformed by the model. Primary content is typically used in conjunction with instructions. A simple example would be language translation. In the example below, the English text would be considered the primary content while "Translate to French:" is an instruction.

+The example above illustrates the utility of few-shot learning. Without the examples, the model seems to be guessing at the desired behavior, while the examples cleanly show the model how to operate. This also demonstrates the power of the model, it can infer the category of label that is wanted, even without a "basketball" label in the examples.

+Cues act as the "jumpstart" for the output of the model, helping to direct the model to the desired output. It is often a prefix that the model can build onto. In the example below, we show the cue directing the story to include key elements. Cues are often used along with instructions, but not always. In the examples below, the model is being used to summarize a long announcement email. A cue is used in one case to help focus the output of the model and to suggest a specific output format (bullet points) in the other.

+| 1 | Performance reviews are a core component of our Performance & Development approach at Contoso. […] <br> Summarize the above email message:<br> The key takeaway of the message is | that Contoso is improving the performance review experience by making it more focused on core priorities, expectations, and impact. Additionally, they are upgrading the in-tool user experience with tips, resources, and guidance. Finally, they are adding guidance on how to activate company-wide core priorities. |

+- **Double Down**. Sometimes you might need to repeat yourself to the model. Give instructions before and after your primary content, use an instruction and a cue, etc.

+- **Order Matters**. The order in which you present information to the model might impact the output. Whether you put instructions before your content (“summarize the following…”) or after (“summarize the above…”) can make a difference in output. Even the order of few-shot examples can matter. This is referred to as recency bias.

+- **Give the model an ΓÇ£outΓÇ¥**. It can sometimes be helpful to give the model an alternative path if it is unable to complete the assigned task. For example, when asking a question over a piece of text you might include something like "respond with "not found" if the answer is not present." This can help the model avoid generating false responses.

+While the input size increases with each new generation of GPT models, there will continue to be scenarios that provide more data than the model can handle. GPT models break words into "tokens." While common multi-syllable words are often a single token, less common words are broken in syllables. Tokens can sometimes be counter-intuitive, as shown by the example below which demonstrates token boundaries for different date formats. In this case, spelling out the entire month is more space efficient than a fully numeric date. The current range of token support goes from 2,000 tokens with earlier GPT-3 models to up to 32,768 tokens with the 32k version of the latest GPT-4 model.

+[Learn more about Azure OpenAI.](../overview.md)

+curl https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/embeddings?api-version=2024-02-01\

+ api_version = "2024-02-01",

+openai.api_version = "2024-02-01"

+ api_version = '2024-02-01' # this may change in the future

+* `gpt-35-turbo` (0125)

+* `gpt-4` (1106-Preview)

+* `gpt-4` (0125-Preview)

+### API support

+Support for parallel function was first added in API version [`2023-12-01-preview`](https://github.com/Azure/azure-rest-api-specs/blob/main/specification/cognitiveservices/data-plane/AzureOpenAI/inference/preview/2023-12-01-preview/inference.json)

+ api_version="2024-03-01-preview"

+* `gpt-35-turbo` (1106)

+* `gpt-35-turbo` (0125)

+* `gpt-4` (1106-Preview)

+* `gpt-4` (0125-Preview)

+### API support

+Support for JSON mode was first added in API version [`2023-12-01-preview`](https://github.com/Azure/azure-rest-api-specs/blob/main/specification/cognitiveservices/data-plane/AzureOpenAI/inference/preview/2023-12-01-preview/inference.json)

+ api_version="2024-03-01-preview"

+ model="gpt-4-0125-Preview", # Model = should match the deployment name you chose for your 0125-Preview model deployment

+ api_version = '2024-03-01-preview' # may change in the future

+ api_version="2024-02-01"

+openai.api_version = "2024-02-01"

+ api_version="2024-02-01",

+openai.api_version = '2024-02-01' # this might change in the future

+ api_version = "2024-02-01",

+openai.api_version = "2024-02-01"

+ api_version = "2024-02-01",

+api_version = "2024-02-01"

+> [!NOTE]

+> The **Provisioned-managed Utilization** metric is now deprecated and is no longer recommended. This metric has been replaced by the **Provisioned-managed Utilization V2** metric.

+| `Provision-managed Utilization V2` | Usage | Average | Provision-managed utilization is the utilization percentage for a given provisioned-managed deployment. Calculated as (PTUs consumed/PTUs deployed)*100. When utilization is at or above 100%, calls are throttled and return a 429 error code. | `ModelDeploymentName`,`ModelName`,`ModelVersion`, `Region`, `StreamType`|

+ api_version="2024-02-01"

+ api_version="2024-02-01",

+curl --location --request PUT 'https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/raiBlocklists/{raiBlocklistName}?api-version=2024-03-01-preview' \

+curl --location --request PUT 'https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/raiPolicies/{raiPolicyName}?api-version=2024-03-01-preview' \

+curl --location --request PUT 'https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.CognitiveServices/accounts/{accountName}/raiBlocklists/{raiBlocklistName}/raiBlocklistItems/{raiBlocklistItemName}?api-version=2024-03-01-preview' \

+## Updating the web app

+We recommend pulling changes from the `main` branch for the web app's source code frequently to ensure you have the latest bug fixes, API version, and improvements. Additionally, the web app must be synchronized every time the API version being used is [retired](../api-version-deprecation.md#retiring-soon).

+**If you haven't customized the app:**

+* You can follow the synchronization steps below

+**If you've customized or changed the app's source code:**

+* You will need to update your app's source code manually and redeploy it.

+ * If your app is hosted on GitHub, push your code changes to your repo, and use the synchronization steps below.

+ * If you're redeploying the app manually (for example Azure CLI), follow the steps for your deployment strategy.

+### Synchronize the web app

+1. If you've customized your app, update the app's source code.

+1. Navigate to your web app in the [Azure portal](https://portal.azure.com/).

+1. Select **Deployment center** in the navigation menu, under **Deployment**.

+1. Select **Sync** at the top of the screen, and confirm that the app will be redeployed.

+ :::image type="content" source="../media/use-your-data/sync-app.png" alt-text="A screenshot of web app synchronization button on the Azure portal." lightbox="../media/use-your-data/sync-app.png":::

+POST https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/completions?api-version=2024-02-01

+curl https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/completions?api-version=2024-02-01\

+curl https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/embeddings?api-version=2024-02-01 \

+curl https://YOUR_RESOURCE_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT_NAME/chat/completions?api-version=2024-02-01 \

+ api_version="2024-02-01" # This API version or later is required to access fine-tuning for turbo/babbage-002/davinci-002

+openai.api_version = '2024-02-01' # This API version or later is required to access fine-tuning for turbo/babbage-002/davinci-002

+ api_version="2024-02-01"

+openai.api_version = "2024-02-01"

+After you publish your custom lexicon, you can reference it from your SSML. The following SSML example references a custom lexicon that was uploaded to `https://www.example.com/customlexicon.xml`. We support lexicon URLs from Azure Blob Storage, Advanced Media Services (AMS) Storage, and GitHub. However, note that other public URLs may not be compatible.

+Now that the managed identity is enabled, assign it the Azure API Center Compliance Manager role to access the API center.

+1. In the [Azure portal](https://portal.azure.com), navigate to your API center and select **Access control (IAM)**.

+1. Select **Job function roles** and then select **Azure API Center Compliance Manager**. Select **Next**.

+1. Assign the function app's managed identity the Azure API Center Compliance Manager role in the API center using the [az role assignment create](/cli/azure/role/assignment#az-role-assignment-create) command.

+ --role "Azure API Center Compliance Manager" \

+ --role "Azure API Center Compliance Manager" `

+1. In the [Azure portal](https://portal.azure.com), navigate to your API center and select **Events**.

+1. On the **Get started** tab, select **Azure Function**.

+1. In the portal, navigate to the API version in your API center where you added or updated an API definition.

+1. In the portal, navigate to your API center.

+The App Service domain you bought is valid for one year from the time of purchase. You can configure to renew your domain automatically, or you can also manually renew your domain name up to 90 days ahead of domain expiration. Upon successful auto or manual renewal, you will be billed for the cost of the domain and your domain expiration will be extended for another year.

+Arc resource bridge doesn't support private link. All calls coming from the appliance VM shouldn't be going through your private link setup. The Private Link IPs may conflict with the appliance IP pool range, which isn't configurable on the resource bridge. Arc resource bridge reaches out to [required URLs](network-requirements.md#firewallproxy-url-allowlist) that shouldn't go through a private link connection. You must deploy Arc resource bridge on a separate network segment unrelated to the private link setup.

+Select **Activity log** to view actions done to your cache. You can also use filtering to expand this view to include other resources. For more information on working with audit logs, see [Audit operations with Resource Manager](/azure/azure-monitor/essentials/activity-log). For more information on monitoring the activity log, see [Activity log](monitor-cache.md#azure-activity-log).

+The **Access control (IAM)** section provides support for Azure role-based access control (Azure RBAC) in the Azure portal. This configuration helps organizations meet their access management requirements simply and precisely. For more information, see [Azure role-based access control in the Azure portal](/azure/role-based-access-control/role-assignments-portal).

+The **Tags** section helps you organize your resources. For more information, see [Using tags to organize your Azure resources](/azure/azure-resource-manager/management/tag-resources).

+The Event Grid helps you build automation into your cloud infrastructure, create serverless apps, and integrate across services and clouds. For more information, see [What is Azure Event Grid](/azure/event-grid/overview).

+For information on moving resources from one resource group to another, and from one subscription to another, see [Move resources to new resource group or subscription](/azure/azure-resource-manager/management/move-resource-group-and-subscription).

+The **Locks** section allows you to lock a subscription, resource group, or resource to prevent other users in your organization from accidentally deleting or modifying critical resources. For more information, see [Lock resources with Azure Resource Manager](/azure/azure-resource-manager/management/lock-resources).

+The **Monitoring** section allows you to configure diagnostics and monitoring for your Azure Cache for Redis instance.

+- For more information on Azure Cache for Redis monitoring and diagnostics, see [Monitor Azure Cache for Redis](monitor-cache.md).

+- For information on how to set up and use Azure Cache for Redis monitoring and diagnostics, see [How to monitor Azure Cache for Redis](cache-how-to-monitor.md).

+Use **Insights** to see groups of predefined tiles and charts to use as starting point for your cache metrics. For more information, see [Insights](monitor-cache.md#insights).

+Select **Metrics** to create your own custom chart to track the metrics you want to see for your cache. For more information, see [Create your own metrics](cache-how-to-monitor.md#create-your-own-metrics).

+By default, cache metrics in Azure Monitor are [stored for 30 days](/azure/azure-monitor/essentials/data-platform-metrics) and then deleted. To persist your cache metrics for longer than 30 days, select **Diagnostics settings** to [configure the storage account](monitor-cache.md#data-storage) used to store cache diagnostics.

+>In addition to archiving your cache metrics to storage, you can also [stream them to an Event hub or send them to Azure Monitor logs](/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs).

+For more information, see [Manage Azure resources and monitor costs by creating automation tasks](/azure/logic-apps/create-automation-tasks-azure-resources).

+Select **Export template** to build and export a template of your deployed resources for future deployments. For more information about working with templates, see [Deploy resources with Azure Resource Manager templates](/azure/azure-resource-manager/templates/deploy-powershell).

+**Resource health** watches your resource and tells you if it's running as expected. For more information about the Azure Resource health service, see [Azure Resource health overview](/azure/service-health/resource-health-overview).

+ Title: How to monitor Azure Cache for Redis

+description: Learn how to monitor the health and performance of your Azure Cache for Redis instances.

+# How to monitor Azure Cache for Redis

+Azure Cache for Redis uses [Azure Monitor](/azure/azure-monitor/index) to provide several options for monitoring your cache instances. Use these tools to monitor the health of your Azure Cache for Redis instances and to help you manage your caching applications.

+To configure a different retention policy, see [Data storage](monitor-cache.md#data-storage). For more information about the different `INFO` values used for each cache metric, see [Create your own metrics](#create-your-own-metrics).

+For detailed information about all the monitoring options available for Azure Cache for Redis, see [Monitor Azure Cache for Redis](monitor-cache.md).

+<a name="use-a-storage-account-to-export-cache-metrics"></a>

+<a name="list-of-metrics"></a>

+<a name="monitor-azure-cache-for-redis"></a>

+You can view Azure Monitor metrics for Azure Cache for Redis directly from an Azure Cache for Redis resource in the [Azure portal](https://portal.azure.com).

+[Select your Azure Cache for Redis instance](cache-configure.md#configure-azure-cache-for-redis-settings) in the portal. The **Overview** page shows the predefined **Memory Usage** and **Redis Server Load** monitoring charts. These charts are useful summaries that allow you to take a quick look at the state of your cache.

+For more in-depth information, you can monitor the following useful Azure Cache for Redis metrics from the **Monitoring** section of the Resource menu.

+| Azure Cache for Redis metric | More information |

+| | |

+| Network bandwidth usage |[Cache performance - available bandwidth](cache-planning-faq.yml#azure-cache-for-redis-performance) |

+| Connected clients |[Default Redis server configuration - max clients](cache-configure.md#maxclients) |

+| Server load |[Redis Server Load](monitor-cache-reference.md#azure-cache-for-redis-metrics) |

+| Memory usage |[Cache performance - size](cache-planning-faq.yml#azure-cache-for-redis-performance) |

+For a complete list and description of metrics you can monitor, see [Azure Cache for Redis metrics](monitor-cache-reference.md#azure-cache-for-redis-metrics).

+The other options under **Monitoring** provide other ways to monitor your caches. For detailed information, see [Monitor Azure Cache for Redis](monitor-cache.md).

+For more information about configuring and using alerts, see [Overview of Alerts](/azure/azure-monitor/alerts/alerts-classic-portal) and [Azure Cache for Redis alerts](monitor-cache.md#alerts).

+- [Monitor Azure Cache for Redis](monitor-cache.md)

+- [Azure Monitor Insights for Azure Cache for Redis](redis-cache-insights-overview.md)

+- [Azure Cache for Redis monitoring data reference](monitor-cache-reference.md)

+- [Azure Monitor Metrics REST API](/azure/azure-monitor/essentials/stream-monitoring-data-event-hubs)

+ Title: Azure Monitor insights for Azure Cache for Redis | Microsoft Docs

+description: This article describes Azure Monitor insights for Azure Cache for Redis, which provides cache owners with a quick understanding of performance and utilization.

+# Azure Monitor insights for Azure Cache for Redis

+Azure Monitor insights for Azure Cache for Redis provide a unified, interactive view of cache performance, failures, capacity, and operational health. This article shows you how to view Azure Cache for Redis insights across all of your subscriptions, and how to modify and adapt insights to fit the unique needs of your organization.

+For more information about Azure Monitor for Azure Cache for Redis, see [Monitor Azure Cache for Redis](monitor-cache.md). For a full list of the metric definitions that form these insights, see [Supported metrics for Microsoft.Cache/redis](monitor-cache-reference.md#supported-metrics-for-microsoftcacheredis).

+## View insights from Azure Monitor

+You can access Azure Cache for Redis insights from the **Insights Hub** of Azure Monitor.

+## Workbooks

+Azure Cache for Redis insights are based on the [workbooks feature of Azure Monitor](/azure/azure-monitor/visualize/workbooks-overview) that provides rich visualizations for metrics and other data. Azure Cache for Redis insights provides two workbooks by default:

+ :::image type="content" source="media/cache-how-to-monitor/cache-monitoring-workbook.png" alt-text="Screenshot showing the workbooks selected in the Resource menu.":::

+- **Azure Cache For Redis Resource Overview** combines many of the most commonly used metrics so that the health and performance of the cache instance can be viewed at a glance.

+ :::image type="content" source="media/cache-how-to-monitor/cache-monitoring-resource-overview.png" alt-text="Screenshot of graphs showing a resource overview for the cache.":::

+- **Geo-Replication Dashboard** pulls geo-replication health and status metrics from both the geo-primary and geo-secondary cache instances to give a complete picture of geo-replcation health. Using this dashboard is recommended, as some geo-replication metrics are only emitted from either the geo-primary or geo-secondary.

+ :::image type="content" source="media/cache-how-to-monitor/cache-monitoring-geo-dashboard.png" alt-text="Screenshot showing the geo-replication dashboard with a geo-primary and geo-secondary cache set.":::

+## View insights from an Azure Cache for Redis resource

+## Customize Azure Monitor insights for Azure Cache for Redis

+## Related content

+- [Create interactive reports with Azure Monitor workbooks](/azure/azure-monitor/visualize/workbooks-overview)

+- [Troubleshoot workbook-based insights](/azure/azure-monitor/insights/troubleshoot-workbooks)

+- [Configure metric alerts](/azure/azure-monitor/alerts/alerts-metric)

+- [Configure service health notifications](/azure/service-health/alerts-activity-log-service-notifications-portal)

+ Title: Monitoring data reference for Azure Cache for Redis

+description: This article contains important reference material you need when you monitor Azure Cache for Redis.

+# Azure Cache for Redis monitoring data reference

+See [Monitor Azure Cache for Redis](monitor-cache.md) for details on the data you can collect for Azure Cache for Redis and how to use it.

+For more details and information about the supported metrics for Microsoft.Cache/redis and Microsoft.Cache/redisEnterprise, see [List of metrics](monitor-cache-reference.md#azure-cache-for-redis-metrics).

+### Supported metrics for Microsoft.Cache/redis

+The following table lists the metrics available for the Microsoft.Cache/redis resource type.

+### Supported metrics for Microsoft.Cache/redisEnterprise

+The following table lists the metrics available for the Microsoft.Cache/redisEnterprise resource type.

+<a name="available-metrics-and-reporting-intervals"></a>

+<a name="create-your-own-metrics"></a>

+<a name="metrics-details"></a>

+## Azure Cache for Redis metrics

+The following list provides details and more information about the supported Azure Monitor metrics for [Microsoft.Cache/redis](/azure/azure-monitor/reference/supported-metrics/microsoft-cache-redis-metrics) and [Microsoft.Cache/redisEnterprise](/azure/azure-monitor/reference/supported-metrics/microsoft-cache-redisenterprise-metrics).

+- 99th Percentile Latency (preview)

+ - Depicts the worst-case (99th percentile) latency of server-side commands. Measured by issuing `PING` commands from the load balancer to the Redis server and tracking the time to respond.

+ - Useful for tracking the health of your Redis instance. Latency increases if the cache is under heavy load or if there are long running commands that delay the execution of the `PING` command.

+ - This metric is only available in Standard and Premium tier caches.

+ - This metric is not available for caches that are affected by Cloud Service retirement. See more information [here](cache-faq.yml#caches-with-a-dependency-on-cloud-services--classic)

+- Cache Latency (preview)

+ - The latency of the cache calculated using the internode latency of the cache. This metric is measured in microseconds, and has three dimensions: `Avg`, `Min`, and `Max`. The dimensions represent the average, minimum, and maximum latency of the cache during the specified reporting interval.

+- Cache Misses

+ - The number of failed key lookups during the specified reporting interval. This number maps to `keyspace_misses` from the Redis INFO command. Cache misses don't necessarily mean there's an issue with the cache. For example, when using the cache-aside programming pattern, an application looks first in the cache for an item. If the item isn't there (cache miss), the item is retrieved from the database and added to the cache for next time. Cache misses are normal behavior for the cache-aside programming pattern. If the number of cache misses is higher than expected, examine the application logic that populates and reads from the cache. If items are being evicted from the cache because of memory pressure, then there might be some cache misses, but a better metric to monitor for memory pressure would be `Used Memory` or `Evicted Keys`.

+- Cache Miss Rate

+ - The percent of unsuccessful key lookups during the specified reporting interval. This metric isn't available in Enterprise or Enterprise Flash tier caches.

+- Cache Read

+ - The amount of data read from the cache in Megabytes per second (MB/s) during the specified reporting interval. This value is derived from the network interface cards that support the virtual machine that hosts the cache and isn't Redis specific. This value corresponds to the network bandwidth used by this cache. If you want to set up alerts for server-side network bandwidth limits, then create it using this `Cache Read` counter. See [this table](./cache-planning-faq.yml#azure-cache-for-redis-performance) for the observed bandwidth limits for various cache pricing tiers and sizes.

+- Cache Write

+ - The amount of data written to the cache in Megabytes per second (MB/s) during the specified reporting interval. This value is derived from the network interface cards that support the virtual machine that hosts the cache and isn't Redis specific. This value corresponds to the network bandwidth of data sent to the cache from the client.

+- Connected Clients

+ - The number of client connections to the cache during the specified reporting interval. This number maps to `connected_clients` from the Redis INFO command. Once the [connection limit](cache-configure.md#default-redis-server-configuration) is reached, later attempts to connect to the cache fail. Even if there are no active client applications, there might still be a few instances of connected clients because of internal processes and connections.

+- Connected Clients Using Microsoft Entra Token (preview)

+ - The number of client connections to the cache authenticated using Microsoft Entra token during the specified reporting interval.

+- Connections Created Per Second

+ - The number of instantaneous connections created per second on the cache via port 6379 or 6380 (SSL). This metric can help identify whether clients are frequently disconnecting and reconnecting, which can cause higher CPU usage and Redis Server Load. This metric isn't available in Enterprise or Enterprise Flash tier caches.

+- Connections Closed Per Second

+ - The number of instantaneous connections closed per second on the cache via port 6379 or 6380 (SSL). This metric can help identify whether clients are frequently disconnecting and reconnecting, which can cause higher CPU usage and Redis Server Load. This metric isn't available in Enterprise or Enterprise Flash tier caches.

+- CPU

+ - The CPU utilization of the Azure Cache for Redis server as a percentage during the specified reporting interval. This value maps to the operating system `\Processor(_Total)\% Processor Time` performance counter. Note that this metric can be noisy due to low priority background security processes running on the node, so we recommend monitoring Server Load metric to track load on a Redis server.

+- Errors

+ - Specific failures and performance issues that the cache could be experiencing during a specified reporting interval. This metric has eight dimensions representing different error types. The error types represented now are as follows:

+ - **Failover** ΓÇô when a cache fails over (subordinate promotes to primary)

+ - **Dataloss** ΓÇô when there's data loss on the cache

+ - **UnresponsiveClients** ΓÇô when the clients aren't reading data from the server fast enough, and specifically, when the number of bytes in the Redis server output buffer for a client goes over 1,000,000 bytes

+ - **AOF** ΓÇô when there's an issue related to AOF persistence

+ - **RDB** ΓÇô when there's an issue related to RDB persistence

+ - **Import** ΓÇô when there's an issue related to Import RDB

+ - **Export** ΓÇô when there's an issue related to Export RDB

+ - **AADAuthenticationFailure** (preview) - when there's an authentication failure using Microsoft Entra access token

+ - **AADTokenExpired** (preview) - when a Microsoft Entra access token used for authentication isn't renewed and it expires.

+- Evicted Keys

+ - The number of items evicted from the cache during the specified reporting interval because of the `maxmemory` limit.

+ - This number maps to `evicted_keys` from the Redis INFO command.

+- Expired Keys

+ - The number of items expired from the cache during the specified reporting interval. This value maps to `expired_keys` from the Redis INFO command.

+- Geo-replication metrics

+ Geo-replication metrics are affected by monthly internal maintenance operations. The Azure Cache for Redis service periodically patches all caches with the latest platform features and improvements. During these updates, each cache node is taken offline, which temporarily disables the geo-replication link. If your geo replication link is unhealthy, check to see if it was caused by a patching event on either the geo-primary or geo-secondary cache by using **Diagnose and Solve Problems** from the Resource menu in the portal. Depending on the amount of data in the cache, the downtime from patching can take anywhere from a few minutes to an hour. If the geo-replication link is unhealthy for over an hour, [file a support request](../azure-portal/supportability/how-to-create-azure-support-request.md).

+ The [Geo-Replication Dashboard](cache-insights-overview.md#workbooks) workbook is a simple and easy way to view all Premium-tier geo-replication metrics in the same place. This dashboard pulls together metrics that are only emitted by the geo-primary or geo-secondary, so they can be viewed simultaneously.

+ - Geo Replication Connectivity Lag

+ - Depicts the time, in seconds, since the last successful data synchronization between geo-primary & geo-secondary. If the link goes down, this value continues to increase, indicating a problem.

+ - This metric is only emitted **from the geo-secondary** cache instance. On the geo-primary instance, this metric has no value.

+ - This metric is only available in the Premium tier for caches with geo-replication enabled.

+ - Geo Replication Data Sync Offset

+ - Depicts the approximate amount of data in bytes that has yet to be synchronized to geo-secondary cache.

+ - This metric is only emitted _from the geo-primary_ cache instance. On the geo-secondary instance, this metric has no value.

+ - This metric is only available in the Premium tier for caches with geo-replication enabled.

+ - Geo Replication Full Sync Event Finished

+ - Depicts the completion of full synchronization between geo-replicated caches. When you see lots of writes on geo-primary, and replication between the two caches canΓÇÖt keep up, then a full sync is needed. A full sync involves copying the complete data from geo-primary to geo-secondary by taking an RDB snapshot rather than a partial sync that occurs on normal instances. See [this page](https://redis.io/docs/manual/replication/#how-redis-replication-works) for a more detailed explanation.

+ - The metric reports zero most of the time because geo-replication uses partial resynchronizations for any new data added after the initial full synchronization.

+ - This metric is only emitted _from the geo-secondary_ cache instance. On the geo-primary instance, this metric has no value.

+ - This metric is only available in the Premium tier for caches with geo-replication enabled.

+ - Geo Replication Full Sync Event Started

+ - Depicts the start of full synchronization between geo-replicated caches. When there are many writes in geo-primary, and replication between the two caches canΓÇÖt keep up, then a full sync is needed. A full sync involves copying the complete data from geo-primary to geo-secondary by taking an RDB snapshot rather than a partial sync that occurs on normal instances. See [this page](https://redis.io/docs/manual/replication/#how-redis-replication-works) for a more detailed explanation.

+ - The metric reports zero most of the time because geo-replication uses partial resynchronizations for any new data added after the initial full synchronization.

+ - The metric is only emitted _from the geo-secondary_ cache instance. On the geo-primary instance, this metric has no value.

+ - The metric is only available in the Premium tier for caches with geo-replication enabled.

+ - Geo Replication Healthy

+ - Depicts the status of the geo-replication link between caches. There can be two possible states that the replication link can be in:

+ - 0 disconnected/unhealthy

+ - 1 ΓÇô healthy

+ - The metric is available in the Enterprise, Enterprise Flash tiers, and Premium tier caches with geo-replication enabled.

+ - In caches on the Premium tier, this metric is only emitted _from the geo-secondary_ cache instance. On the geo-primary instance, this metric has no value.

+ - This metric might indicate a disconnected/unhealthy replication status for several reasons, including: monthly patching, host OS updates, network misconfiguration, or failed geo-replication link provisioning.

+ - A value of 0 doesn't mean that data on the geo-replica is lost. It just means that the link between geo-primary and geo-secondary is unhealthy.

+ - If the geo-replication link is unhealthy for over an hour, [file a support request](../azure-portal/supportability/how-to-create-azure-support-request.md).

+- Gets

+ - The number of get operations from the cache during the specified reporting interval. This value is the sum of the following values from the Redis INFO all command: `cmdstat_get`, `cmdstat_hget`, `cmdstat_hgetall`, `cmdstat_hmget`, `cmdstat_mget`, `cmdstat_getbit`, and `cmdstat_getrange`, and is equivalent to the sum of cache hits and misses during the reporting interval.

+- Operations per Second

+ - The total number of commands processed per second by the cache server during the specified reporting interval. This value maps to "instantaneous_ops_per_sec" from the Redis INFO command.

+- Server Load

+ - The percentage of CPU cycles in which the Redis server is busy processing and _not waiting idle_ for messages. If this counter reaches 100, the Redis server has hit a performance ceiling, and the CPU can't process work any faster. You can expect a large latency effect. If you're seeing a high Redis Server Load, such as 100, because you're sending many expensive commands to the server, then you might see timeout exceptions in the client. In this case, you should consider scaling up, scaling out to a Premium cluster, or partitioning your data into multiple caches. When _Server Load_ is only moderately high, such as 50 to 80 percent, then average latency usually remains low, and timeout exceptions could have other causes than high server latency.

+ - The _Server Load_ metric is sensitive to other processes on the machine using the existing CPU cycles that reduce the Redis server's idle time. For example, on the _C1_ tier, background tasks such as virus scanning cause _Server Load_ to spike higher for no obvious reason. We recommended that you pay attention to other metrics such as operations, latency, and CPU, in addition to _Server Load_.

+

+ > [!CAUTION]

+ > The _Server Load_ metric can present incorrect data for Enterprise and Enterprise Flash tier caches. Sometimes _Server Load_ is represented as being over 100. We are investigating this issue. We recommend using the CPU metric instead in the meantime.

+- Sets

+ - The number of set operations to the cache during the specified reporting interval. This value is the sum of the following values from the Redis INFO all command: `cmdstat_set`, `cmdstat_hset`, `cmdstat_hmset`, `cmdstat_hsetnx`, `cmdstat_lset`, `cmdstat_mset`, `cmdstat_msetnx`, `cmdstat_setbit`, `cmdstat_setex`, `cmdstat_setrange`, and `cmdstat_setnx`.

+- Total Keys

+ - The maximum number of keys in the cache during the past reporting time period. This number maps to `keyspace` from the Redis INFO command. Because of a limitation in the underlying metrics system for caches with clustering enabled, Total Keys return the maximum number of keys of the shard that had the maximum number of keys during the reporting interval.

+- Total Operations

+ - The total number of commands processed by the cache server during the specified reporting interval. This value maps to `total_commands_processed` from the Redis INFO command. When Azure Cache for Redis is used purely for pub/sub, there are no metrics for `Cache Hits`, `Cache Misses`, `Gets`, or `Sets`, but there are `Total Operations` metrics that reflect the cache usage for pub/sub operations.

+- Used Memory

+ - The amount of cache memory in MB that is used for key/value pairs in the cache during the specified reporting interval. This value maps to `used_memory` from the Redis INFO command. This value doesn't include metadata or fragmentation.

+ - On the Enterprise and Enterprise Flash tier, the Used Memory value includes the memory in both the primary and replica nodes. This can make the metric appear twice as large as expected.

+- Used Memory Percentage

+ - The percent of total memory that is being used during the specified reporting interval. This value references the `used_memory` value from the Redis INFO command to calculate the percentage. This value doesn't include fragmentation.

+- Used Memory RSS

+ - The amount of cache memory used in MB during the specified reporting interval, including fragmentation. This value maps to `used_memory_rss` from the Redis INFO command. This metric isn't available in Enterprise or Enterprise Flash tier caches.

+### Supported resource logs for Microsoft.Cache/redis

+### Supported resource logs for Microsoft.Cache/redisEnterprise/databases

+### Azure Cache for Redis

+microsoft.cache/redis

+- [ACRConnectedClientList](/azure/azure-monitor/reference/tables/acrconnectedclientlist)

+- [AzureActivity](/azure/azure-monitor/reference/tables/azureactivity)

+- [AzureMetrics](/azure/azure-monitor/reference/tables/azuremetrics)

+### Azure Cache for Redis Enterprise

+Microsoft.Cache/redisEnterprise

+- [REDConnectionEvents](/azure/azure-monitor/reference/tables/redconnectionevents)

+- [Microsoft.Cache resource provider operations](/azure/role-based-access-control/resource-provider-operations#microsoftcache)

+## Related content

+- See [Monitor Azure Cache for Redis](monitor-cache.md) for a description of monitoring Azure Cache for Redis.

+- See [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for details on monitoring Azure resources.

+ Title: Monitor Azure Cache for Redis

+description: Start here to learn how to monitor Azure Cache for Redis.

+# Monitor Azure Cache for Redis

+Insights for Azure Cache for Redis deliver the following experience:

+- **At scale perspective** of your Azure Cache for Redis resources across subscriptions. You can selectively scope to only the subscriptions and resources you want to evaluate.

+- **Drill-down analysis** of an Azure Cache for Redis resource. To diagnose problems, you can see detailed analysis of utilization, failures, capacity, and operations, or see an in-depth view of relevant information.

+- **Customization** built on Azure Monitor workbook templates. You can change what metrics are displayed and modify or set thresholds that align with your limits. You can save the changes in a custom workbook and then pin workbook charts to Azure dashboards.

+Insights for Azure Cache for Redis don't require you to enable or configure anything. Azure Cache for Redis information is collected by default, and there's no extra charge to access insights.

+To learn how to view, configure, and customize insights for Azure Cache for Redis, see [Azure Monitor insights for Azure Cache for Redis](cache-insights-overview.md).

+For more information about the resource types for Azure Cache for Redis, see [Azure Cache for Redis monitoring data reference](monitor-cache-reference.md).

+<a name="use-a-storage-account-to-export-azure-cache-for-redis-metrics"></a>

+For a list of available metrics for Azure Cache for Redis, see [Azure Cache for Redis monitoring data reference](monitor-cache-reference.md#metrics).

+For the available resource log categories, their associated Log Analytics tables, and the logs schemas for Azure Cache for Redis, see [Azure Cache for Redis monitoring data reference](monitor-cache-reference.md#resource-logs).

+## Azure Cache for Redis resource logs

+In Azure Cache for Redis, two options are available to log:

+- **Cache Metrics** ("AllMetrics") [logs metrics from Azure Monitor](/azure/azure-monitor/essentials/diagnostic-settings?tabs=portal)

+- **Connection Logs** logs connections to the cache for security and diagnostic purposes.

+### Cache metrics

+Azure Cache for Redis emits many metrics such as `Server Load` and `Connections per Second` that are useful to log. Selecting the **AllMetrics** option allows these and other cache metrics to be logged. You can configure how long to retain the metrics.

+### Connection logs

+Azure Cache for Redis uses Azure diagnostic settings to log information on client connections to your cache. Logging and analyzing this diagnostic setting helps you understand who is connecting to your caches and the timestamp of those connections. The log data could be used to identify the scope of a security breach and for security auditing purposes.

+The connection logs have slightly different implementations, contents, and setup procedures for the different Azure Cache for Redis tiers. For details, see [Azure Monitor diagnostic settings](cache-monitor-diagnostic-settings.md).

+## Azure Cache for Redis metrics

+Metrics for Azure Cache for Redis instances are collected using the Redis [`INFO`](https://redis.io/commands/info) command. Metrics are collected approximately two times per minute and automatically stored for 30 days so they can be displayed in the metrics charts and evaluated by alert rules.

+The metrics are reported using several reporting intervals, including **Past hour**, **Today**, **Past week**, and **Custom**. Each metrics chart displays the average, minimum, and maximum values for each metric in the chart, and some metrics display a total for the reporting interval.

+Each metric includes two versions: One metric measures performance for the entire cache, and for caches that use clustering. A second version of the metric, which includes `(Shard 0-9)` in the name, measures performance for a single shard in a cache. For example if a cache has four shards, `Cache Hits` is the total number of hits for the entire cache, and `Cache Hits (Shard 3)` measures just the hits for that shard of the cache.

+#### Aggregation types

+For general information about aggregation types, see [Configure aggregation](/azure/azure-monitor/essentials/analyze-metrics#configure-aggregation).

+Under normal cache conditions, **Average** and **Max** are similar because only the primary node emits these metrics. In a scenario where the number of connected clients changes rapidly, **Max**, **Average**, and **Min** show different values, which is also expected behavior.

+The types **Count** and **Sum** can be misleading for certain metrics, such as connected clients. Instead, it's best to look at the **Average** metrics and not the **Sum** metrics.

+> [!NOTE]

+> Even when the cache is idle with no connected active client applications, you might see some cache activity, such as connected clients, memory usage, and operations being performed. The activity is normal in the operation of the cache.

+For nonclustered caches, it's best to use the metrics without the suffix `Instance Based`. For example, to check server load for your cache instance, use the metric _Server Load_.

+In contrast, for clustered caches, use the metrics with the suffix `Instance Based`. Then, add a split or filter on `ShardId`. For example, to check the server load of shard 1, use the metric **Server Load (Instance Based)**, then apply filter **ShardId = 1**.

+For sample Kusto queries for Azure Cache for Redis connection logs, see [Connection log queries](cache-monitor-diagnostic-settings.md#log-analytics-queries).

+### Azure Cache for Redis common alert rules

+The following table lists common and recommended alert rules for Azure Cache for Redis.

+| Alert type | Condition | Description |

+|:|:|:|

+|Metric|99th percentile latency|Alert on the worst-case latency of server-side commands in Azure Cache for Redis instances. Latency is measured by using `PING` commands and tracking response times. Track the health of your cache instance to see if long-running commands are compromising latency performance.

+|Metric |High `Server Load` usage or spikes |High server load means the Redis server is unable to keep up with requests, leading to timeouts or slow responses. Create alerts on metrics on server load metrics to be notified early about potential impacts.|

+|Metric |High network bandwidth usage |If the server exceeds the available bandwidth, then data isn't sent to the client as quickly. Client requests could time out because the server can't push data to the client fast enough. Set up alerts for server-side network bandwidth limits by using the `Cache Read` and `Cache Write` counters. |

+The following screenshot shows an advisor recommendation for an Azure Cache for Redis alert:

+To upgrade your cache, select **Upgrade now** to change the pricing tier and [scale](cache-configure.md#scale) your cache. For more information on choosing a pricing tier, see [Choosing the right tier](cache-overview.md#choosing-the-right-tier).

+## Related content

+- See [Azure Cache for Redis monitoring data reference](monitor-cache-reference.md) for a reference of the metrics, logs, and other important values created for Azure Cache for Redis.

+- See [Monitoring Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for general details on monitoring Azure resources.

+description: Learn how to use the .NET isolated worker model to run your C# functions in Azure, which lets you run your functions on currently supported versions of .NET and .NET Framework.

+# Guide for running C# Azure Functions in the isolated worker model

+These configurations apply to your function app running in a separate process. To make changes to the functions host or trigger and binding configuration, you still need to use the [host.json file](functions-host-json.md).

+> [!NOTE]

+> Custom configuration sources cannot be used for configuration of triggers and bindings. Trigger and binding configuration must be available to the Functions platform, and not just your application code. You can provide this configuration through the [application settings](../app-service/configure-common.md#configure-app-settings), [Key Vault references](../app-service/app-service-key-vault-references.md?toc=%2Fazure%2Fazure-functions%2Ftoc.json), or [App Configuration references](../app-service/app-service-configuration-references.md?toc=%2Fazure%2Fazure-functions%2Ftoc.json) features.

+### Customizing JSON serialization

+The isolated worker model uses `System.Text.Json` by default. You can customize the behavior of the serializer by configuring services as part of your `Program.cs` file. The following example shows this using `ConfigureFunctionsWebApplication`, but it will also work for `ConfigureFunctionsWorkerDefaults`:

+```csharp

+var host = new HostBuilder()

+ .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>

+ {

+ builder.Services.Configure<JsonSerializerOptions>(jsonSerializerOptions =>

+ {

+ jsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase;

+ jsonSerializerOptions.DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull;

+ jsonSerializerOptions.ReferenceHandler = ReferenceHandler.Preserve;

+ // override the default value

+ jsonSerializerOptions.PropertyNameCaseInsensitive = false;

+ });

+ })

+ .Build();

+```

+You might wish to instead use JSON.NET (`Newtonsoft.Json`) for serialization. To do this, you would install the [`Microsoft.Azure.Core.NewtonsoftJson`](https://www.nuget.org/packages/Microsoft.Azure.Core.NewtonsoftJson) package. Then, in your service registration, you would reassign the `Serializer` property on the `WorkerOptions` configuration. The following example shows this using `ConfigureFunctionsWebApplication`, but it will also work for `ConfigureFunctionsWorkerDefaults`:

+```csharp

+var host = new HostBuilder()

+ .ConfigureFunctionsWebApplication((IFunctionsWorkerApplicationBuilder builder) =>

+ {

+ builder.Services.Configure<WorkerOptions>(workerOptions =>

+ {

+ var settings = NewtonsoftJsonObjectSerializer.CreateJsonSerializerSettings();

+ settings.ContractResolver = new CamelCasePropertyNamesContractResolver();

+ settings.NullValueHandling = NullValueHandling.Ignore;

+ workerOptions.Serializer = new NewtonsoftJsonObjectSerializer(settings);

+ });

+ })

+ .Build();

+```

+When you deploy your function code project to Azure, it must run in either a function app or in a Linux container. The function app and other required Azure resources must exist before you deploy your code.

+### Project file

+This example includes [ASP.NET Core integration] to improve performance and provide a familiar programming model when your app uses HTTP triggers. If you do not intend to use HTTP triggers, you can replace the call to `ConfigureFunctionsWebApplication` with a call to `ConfigureFunctionsWorkerDefaults`. If you do so, you can remove the reference to `Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore` from your project file. However, for the best performance, even for functions with other trigger types, you should keep the `FrameworkReference` to ASP.NET Core.

+### host.json file

+No changes are required to your `host.json` file. However, if your Application Insights configuration in this file from your in-process model project, you might want to make additional changes in your `Program.cs` file. The `host.json` file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See [Managing log levels in the isolated worker model](./dotnet-isolated-process-guide.md#managing-log-levels) for details on how to filter these logs.

+### Other code changes

+This section highlights other code changes to consider as you work through the migration. These changes are not needed by all applications, but you should evaluate if any are relevant to your scenarios.

+### Project file

+This example includes [ASP.NET Core integration] to improve performance and provide a familiar programming model when your app uses HTTP triggers. If you do not intend to use HTTP triggers, you can replace the call to `ConfigureFunctionsWebApplication` with a call to `ConfigureFunctionsWorkerDefaults`. If you do so, you can remove the reference to `Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore` from your project file. However, for the best performance, even for functions with other trigger types, you should keep the `FrameworkReference` to ASP.NET Core.

+The `host.json` file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See [Managing log levels in the isolated worker model](./dotnet-isolated-process-guide.md#managing-log-levels) for details on how to filter these logs.

+The `host.json` file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See [Managing log levels in the isolated worker model](./dotnet-isolated-process-guide.md#managing-log-levels) for details on how to filter these logs.

+### Other code changes

+# [.NET 8 (isolated)](#tab/net8)

+This section highlights other code changes to consider as you work through the migration. These changes are not needed by all applications, but you should evaluate if any are relevant to your scenarios. Make sure to check [Behavior changes after version 1.x](#behavior-changes-after-version-1x) for additional changes you might need to make to your project.

+# [.NET 6 (in-process)](#tab/net6-in-proc)

+Make sure to check [Behavior changes after version 1.x](#behavior-changes-after-version-1x) for additional changes you might need to make to your project.

+# [.NET Framework 4.8](#tab/netframework48)

+This section highlights other code changes to consider as you work through the migration. These changes are not needed by all applications, but you should evaluate if any are relevant to your scenarios. Make sure to check [Behavior changes after version 1.x](#behavior-changes-after-version-1x) for additional changes you might need to make to your project.

+### Project file

+This example includes [ASP.NET Core integration] to improve performance and provide a familiar programming model when your app uses HTTP triggers. If you do not intend to use HTTP triggers, you can replace the call to `ConfigureFunctionsWebApplication` with a call to `ConfigureFunctionsWorkerDefaults`. If you do so, you can remove the reference to `Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore` from your project file. However, for the best performance, even for functions with other trigger types, you should keep the `FrameworkReference` to ASP.NET Core.

+### host.json file

+# [.NET 8 (isolated)](#tab/net8)

+No changes are required to your `host.json` file. However, if your Application Insights configuration in this file from your in-process model project, you might want to make additional changes in your `Program.cs` file. The `host.json` file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See [Managing log levels in the isolated worker model](./dotnet-isolated-process-guide.md#managing-log-levels) for details on how to filter these logs.

+# [.NET 6 (in-process)](#tab/net6-in-proc)

+No changes are required to your `host.json` file.

+# [.NET Framework 4.8](#tab/netframework48)

+No changes are required to your `host.json` file. However, if your Application Insights configuration in this file from your in-process model project, you might want to make additional changes in your `Program.cs` file. The `host.json` file only controls logging from the Functions host runtime, and in the isolated worker model, some of these logs come from your application directly, giving you more control. See [Managing log levels in the isolated worker model](./dotnet-isolated-process-guide.md#managing-log-levels) for details on how to filter these logs.

+### Other code changes

+# [.NET 8 (isolated)](#tab/net8)

+This section highlights other code changes to consider as you work through the migration. These changes are not needed by all applications, but you should evaluate if any are relevant to your scenarios. Make sure to check [Breaking changes between 3.x and 4.x](#breaking-changes-between-3x-and-4x) for additional changes you might need to make to your project.

+# [.NET 6 (in-process)](#tab/net6-in-proc)

+Make sure to check [Breaking changes between 3.x and 4.x](#breaking-changes-between-3x-and-4x) for additional changes you might need to make to your project.

+# [.NET Framework 4.8](#tab/netframework48)

+This section highlights other code changes to consider as you work through the migration. These changes are not needed by all applications, but you should evaluate if any are relevant to your scenarios. Make sure to check [Breaking changes between 3.x and 4.x](#breaking-changes-between-3x-and-4x) for additional changes you might need to make to your project.

+1. If needed, move to one of the [Java versions supported on version 4.x](./functions-reference-java.md#supported-versions).

+1. Update the app's `POM.xml` file to modify the `FUNCTIONS_EXTENSION_VERSION` setting to `~4`, as in the following example:

+1. Take this opportunity to upgrade to PowerShell 7.2, which is recommended. For more information, see [PowerShell versions](functions-reference-powershell.md#powershell-versions).

+1. If you're using Python 3.6, move to one of the [supported versions](functions-reference-python.md#python-version).

+> [!NOTE]

+>

+> **Azure Maps Web SDK Service Module retirement**

+>

+> The Azure Maps Web SDK Service Module is now deprecated and will be retired on 9/30/26. To avoid service disruptions, we recommend migrating to the Azure Maps JavaScript REST SDK by 9/30/26. For more information, see [JavaScript/TypeScript REST SDK Developers Guide (preview)](how-to-dev-guide-js-sdk.md).

+> [!NOTE]

+>

+> **Azure Maps Web SDK Service Module retirement**

+>

+> The Azure Maps Web SDK Service Module is now deprecated and will be retired on 9/30/26. To avoid service disruptions, we recommend migrating to the Azure Maps JavaScript REST SDK by 9/30/26. For more information, see [JavaScript/TypeScript REST SDK Developers Guide (preview)](how-to-dev-guide-js-sdk.md).

+### [3.2.0] (March 29, 2024)

+#### Other changes (3.2.0)

+- Upgrade MapLibre to [V4](https://github.com/maplibre/maplibre-gl-js/releases/tag/v4.0.0).

+- Correct the default value of `HtmlMarkerOptions.pixelOffset` from `[0, -18]` to `[0, 0]` in the doc.

+- Added `fillAntialias` option to `PolygonLayer` for enabling MSAA antialiasing on polygon fills.

+- Added `fillAntialias` option to `PolygonLayer` for enabling MSAA antialiasing on polygon fills.

+[3.2.0]: https://www.npmjs.com/package/azure-maps-control/v/3.2.0

+## [0.1.8] (February 22, 2024)

+> [!NOTE]

+>

+> **Azure Maps Web SDK Service Module retirement**

+>

+> The Azure Maps Web SDK Service Module is now deprecated and will be retired on 9/30/26. To avoid service disruptions, we recommend migrating to the Azure Maps JavaScript REST SDK by 9/30/26. For more information, see [JavaScript/TypeScript REST SDK Developers Guide (preview)](how-to-dev-guide-js-sdk.md).

+- ***Sentinel***: Windows firewall logs are not yet GA

+> You can use the PowerShell cmdlet `Get-WinEvent` with the `FilterXPath` parameter to test the validity of an XPath query locally on your machine first. For more information, see the tip provided in the [Windows agent-based connections](../../sentinel/connect-services-windows-based.md) instructions. The [`Get-WinEvent`](/powershell/module/microsoft.powershell.diagnostics/get-winevent) PowerShell cmdlet supports up to 23 expressions. Azure Monitor data collection rules support up to 20. The following script shows an example:

+ Ensure you have a public DNS record for your internal website. The test will fail if the target url hostname cannot be resolved by public clients using public DNS. For more information, see [Create a custom domain name for internal application](../../cloud-services/cloud-services-custom-domain-name-portal.md#add-an-a-record-for-your-custom-domain).

+ Title: Sampling overrides - Azure Monitor Application Insights for Java

+# Sampling overrides - Azure Monitor Application Insights for Java

+l

+> [!IMPORTANT]

+> Complete configuration of data collection in Container insights may require editing of both the ConfigMap and the data collection rule (DCR) for the cluster since each method allows configuration of a different set of settings.

+>

+> See [Configure data collection in Container insights using data collection rule](./container-insights-data-collection-dcr.md) for a list of settings and the process to configure data collection using the DCR.

+ Title: Configure data collection and cost optimization in Container insights using data collection rule

+# Configure data collection and cost optimization in Container insights using data collection rule

+This article describes how to configure data collection in Container insights using the [data collection rule (DCR)](../essentials/data-collection-rule-overview.md) for your Kubernetes cluster. This includes preset configurations for optimizing your costs. A DCR is created when you onboard a cluster to Container insights. This DCR is used by the containerized agent to define data collection for the cluster.

+- Enable/disable collection and namespace filtering for performance and inventory data.

+> [!IMPORTANT]

+> Complete configuration of data collection in Container insights may require editing of both the DCR and the ConfigMap for the cluster since each method allows configuration of a different set of settings.

+>

+> See [Configure data collection in Container insights using ConfigMap](./container-insights-data-collection-configmap.md) for a list of settings and the process to configure data collection using ConfigMap.

+> The queries in this article depend on data collected by Container insights and stored in a Log Analytics workspace. If you've modified the default data collection settings, the queries might not return the expected results. Most notably, if you've disabled collection of performance data since you've enabled Prometheus metrics for the cluster, any queries using the `Perf` table won't return results.

+>

+> See [Configure data collection in Container insights using data collection rule](./container-insights-data-collection-dcr.md) for preset configurations including disabling performance data collection. See [Configure data collection in Container insights using ConfigMap](./container-insights-data-collection-configmap.md) for further data collection options.

+

+> [!IMPORTANT]

+> The queries in this article depend on data collected by Container insights and stored in a Log Analytics workspace. If you've modified the default data collection settings, the queries might not return the expected results. Most notably, if you've disabled collection of performance data since you've enabled Prometheus metrics for the cluster, any queries using the `Perf` table won't return results.

+>

+> See [Configure data collection in Container insights using data collection rule](./container-insights-data-collection-dcr.md) for preset configurations including disabling performance data collection. See [Configure data collection in Container insights using ConfigMap](./container-insights-data-collection-configmap.md) for further data collection options.

+> Kubernetes clusters generate a lot of log data, which can result in significant costs if you aren't selective about the logs that you collect. Before you enable monitoring for your cluster, see the following articles to ensure that your environment is optimized for cost and that you limit your log collection to only the data that you require:

+>

+>- [Configure data collection and cost optimization in Container insights using data collection rule](./container-insights-data-collection-dcr.md)<br>Details on customizing log collection once you've enabled monitoring, including using preset cost optimization configurations.

+>- [Best practices for monitoring Kubernetes with Azure Monitor](../best-practices-containers.md)<br>Best practices for monitoring Kubernetes clusters organized by the five pillars of the [Azure Well-Architected Framework](/azure/architecture/framework/), including cost optimization.

+>- [Cost optimization in Azure Monitor](../best-practices-cost.md)<br>Best practices for configuring all features of Azure Monitor to optimize you costs and limit the amount of data that you collect.

+* South India

+You can set up vCenter Server to use an external Lightweight Directory Access Protocol (LDAP) directory service to authenticate users. A user can sign in by using their Windows Server Active Directory account credentials or credentials from a third-party LDAP server. Then, the account can be assigned a vCenter Server role, like in an on-premises environment, to provide role-based access for vCenter Server users.

+## Supported VMware vSphere features

+**Choose a backup tier**:

+# [Snapshot tier](#tab/snapshot-tier)

+# [Vault-standard tier (preview)](#tab/vault-tier)

+Vaulted backup for Azure Files (preview) is available in West Central US, Southeast Asia, UK South, East Asia, UK West, India Central.

+**Choose a backup tier**:

+# [Snapshot tier](#tab/snapshot-tier)

+# [Vault-standard tier (preview)](#tab/vault-tier)

+| Storage account details | Support |

+| | |

+| Account Kind | Azure Backup supports Azure file shares present in general-purpose v2, and file storage type storage accounts. |

+>[!Note]

+>Storage accounts with restricted network access aren't supported.

+**Choose a backup tier**:

+# [Snapshot tier](#tab/snapshot-tier)

+# [Vault-standard tier (preview)](#tab/vault-tier)

+| File share type | Support |

+| -- | |

+| Standard | Supported |

+| Large | Supported |

+| Premium | Supported |

+| File shares connected with Azure File Sync service | Supported |

+**Choose a backup tier**:

+# [Snapshot tier](#tab/snapshot-tier)

+# [Vault-standard tier (preview)](#tab/vault-tier)

+| Setting | Limit |

+| | |

+| Maximum size of file share | 8 TB |

+| Maximum number of files in a file share | 8 million |

+**Choose a backup tier**:

+# [Snapshot tier](#tab/snapshot-tier)

+# [Vault-standard tier (preview)](#tab/vault-tier)

+| Setting | Limit |

+| | |

+| Maximum size of a file | 1 TB |

+>[!Note]

+>Restore to file shares connected with Azure File sync service or with restricted network access isn't supported.

+**Choose a backup tier**:

+# [Snapshot tier](#tab/snapshot-tier)

+# [Vault-standard tier (preview)](#tab/vault-tier)

+| Setting | Limit |

+| | |

+| Maximum retention of snapshot | 30 days |

+| Maximum retention of recovery point created by on-demand backup | 99 years |

+| Maximum retention of daily recovery points | 9999 days |

+| Maximum retention of weekly recovery points | 5163 weeks |

+| Maximum retention of monthly recovery points | 1188 months |

+| Maximum retention of yearly recovery points | 99 years |

+**Choose a backup tier**:

+# [Snapshot tier](#tab/snapshot-tier)

+# [Vault-standard tier (preview)](#tab/vault-tier)

+| Restore method | Description |

+| | |

+| Full Share Restore | You can restore the complete file share to an alternate location

+>[!Note]

+>Original location restores (OLR) and file-level recovery aren't supported. You can perform restore to an empty folder with the **Overwrite** option only.

+ Title: Replace your tape infrastructure by using Azure Backup

+This article describes how you can enable backup and retention policies. If you're using tapes to address your long-term-retention needs, Azure Backup provides a powerful and viable alternative with the availability of this feature. The feature is enabled in the Azure Backup service (which is available [here](https://aka.ms/azurebackup_agent)). If you're using System Center DPM, then you must update to, at least, DPM 2012 R2 UR5 before using DPM with the Azure Backup service.

+Azure Backup and System Center Data Protection Manager enable you to:

+* Back up data in schedules, which best suit the organizational needs.

+* Retain the backup data for longer periods.

+* Make Azure a part of your long-term retention needs (instead of tape).

+

+You can also schedule a weekly backup. For example, the settings in the following screen indicate that backups are taken every alternate Sunday & Wednesday at 9:30AM and 1:00AM.

+

+The retention policy specifies the duration for which the backup must be stored. Rather than just specifying a *flat policy* for all backup points, you can specify different retention policies based on when the backup is taken. For example, the backup point taken daily, which serves as an operational recovery point, is preserved for 90 days. The backup point taken at the end of each quarter for audit purposes is preserved for a longer duration.

+

+## Example protection policy

+

+The total number of ΓÇ£retention pointsΓÇ¥ (points from which you can restore data) in the preceding diagram is computed as follows:

+* Two points per day for seven days = 14 recovery points

+* Two points per week for four weeks = 8 recovery points

+* Two points per month for 12 months = 24 recovery points

+* One point per year per 10 years = 10 recovery points

+By selecting **Modify** in the preceding screen, you have further flexibility in specifying retention schedules.

+

+ Title: Troubleshoot Azure Database for MySQL - Flexible Server backup using Azure Backup

+description: Troubleshooting information for backing up Azure Database for MySQL - Flexible server.

+# Troubleshoot Azure Database for MySQL - Flexible Server backup (preview)

+This article provides the recommended actions to troubleshoot the issues you might encounter during the backup or restore of Azure Database for MySQL - Flexible server.

+## Common errors for the backup and restore operations

+### MySQLFlexOperationFailedUserError

+**Error code**: MySQLFlexOperationFailedUserError

+**Inner error code**: ResourceGroupNotFound

+**Recommended action**: Check if the resource group of the backed-up server is deleted. We recommend you to stop protection for the backup instance to avoid failures.

+### MySQLFlexOperationFailedUserError

+**Error code**: MySQLFlexOperationFailedUserError

+**Inner error code**: ResourceNotFound

+**Recommended action**: Check if the resource being backed up is deleted. We recommend you to stop protection for the backup instance to avoid failures.

+### MySQLFlexOperationFailedUserError

+**Error code**: MySQLFlexOperationFailedUserError

+**Inner error code**: AuthorizationFailed

+**Cause**: Required permissions aren't present to perform the backup operation.

+**Recommended action**: Assign the [appropriate permissions](backup-azure-mysql-flexible-server-about.md#permissions-for-an-azure-database-for-mysqlflexible-server-backup).

+### MySQLFlexClientError

+**Error code**: MySQLFlexClientError

+**Inner error code**: BackupAlreadyRunningForServer

+**Cause**: A backup operation is already running on the server.

+**Recommended action**: Wait for the previous operation to finish before triggering the next backup operation.

+### UserErrorMaxConcurrentOperationLimitReached

+**Error code**: UserErrorMaxConcurrentOperationLimitReached

+**Inner error code**: UserErrorMaxConcurrentOperationLimitReached

+**Cause**: The count to perform backups on the server reached the maximum limit.

+**Recommended action**: Try to trigger a backup once the current running backup job finishes.

+### UserErrorMSIMissingPermissions

+**Error code**: UserErrorMSIMissingPermissions

+**Inner error code**: UserErrorMSIMissingPermissions

+**Cause**: The required set of permissions isn't present to perform the restore operation.

+**Recommended action**: Assign the [appropriate permissions](backup-azure-mysql-flexible-server-about.md#permissions-for-an-azure-database-for-mysqlflexible-server-backup) and retrigger backup operation.

+## Next steps

+- [About long-term retention for Azure Database for MySQL - Flexible Server by using Azure Backup (preview)](backup-azure-mysql-flexible-server-about.md).

+This article describes how to use PowerShell to set up Azure Backup on a DPM server, and to manage backup and recovery.

+## Set up the PowerShell environment

+## Configure the staging Area

+In the example below, the first command converts the string ```passphrase123456789``` to a secure string and assigns the secure string to the variable named ```$Passphrase```. The second command sets the secure string in ```$Passphrase``` as the password for encrypting backups.

+In this section, you'll add a production server to DPM and then protect the data to local DPM storage and then to Azure Backup. In the examples, we'll demonstrate how to back up files and folders. The logic can easily be extended to back up any DPM-supported data source. All your DPM backups are governed by a Protection Group (PG) with four parts:

+### Create a protection group

+### Add group members to the Protection Group

+### Select the data protection method

+Once the datasources have been added to the Protection Group, the next step is to specify the protection method using the [Set-DPMProtectionType](/powershell/module/dataprotectionmanager/set-dpmprotectiontype) cmdlet. In this example, the Protection Group is set up for local disk and cloud backup. You also need to specify the datasource that you want to protect to cloud using the [Add-DPMChildDatasource](/powershell/module/dataprotectionmanager/add-dpmchilddatasource) cmdlet with -Online flag.

+### Set the retention range

+When you back up a datasource for the first time, DPM needs creates initial replica that creates a full copy of the datasource to be protected on DPM replica volume. This activity can either be scheduled for a specific time, or can be triggered manually, using the [Set-DPMReplicaCreationMethod](/powershell/module/dataprotectionmanager/set-dpmreplicacreationmethod) cmdlet with the parameter ```-NOW```.

+### Change the size of DPM Replica & recovery point volume

+### Commit the changes to the Protection Group

+ Title: System state and bare-metal recovery protection for Azure Backup

+This article describes how to back up system state and restore to bare metal by using Azure Backup Server.

+## Supported backup and restore scenarios

+## System state backup workflow

+If the protection server is in a cluster, a cluster drive might be selected as the drive that has the most free space. If that drive ownership is switched to another node and a system state backup run, then the drive is unavailable and the backup fails. In this scenario, modify *PSDataSourceConfig.xml* to point to a local drive.

+* This folder and its contents aren't cleaned up when the backup or transfer finishes. This space is reserved for the next time a backup job completes.

+## BMR backup workflow

+* Short-term protection to tape (disk to tape, or D2T) isn't supported for BMR. Long-term storage to tape (disk to tape, or D2D2T) is supported.

+* Backup Server reserves 30 GB of space on the replica volume for BMR. You can change this space allotment on the **Disk Allocation** blade in the Modify Protection Group Wizard. Or you can use the Get-DatasourceDiskAllocation and Set-DatasourceDiskAllocation PowerShell cmdlets. On the recovery point volume, BMR protection requires about 6 GB for a retention of five days.

+* If you change from system state protection to BMR protection, then BMR protection requires less space on the *recovery point volume*. However, the extra space on the volume isn't reclaimed. You can manually shrink the volume size on the **Modify Disk Allocation** blade of the Modify Protection Group Wizard. Or you can use the Get-DatasourceDiskAllocation and Set-DatasourceDiskAllocation PowerShell cmdlets.

+To back up system state and bare metal, follow these steps:

+1. On the **Select Protection Group Type** blade, select **Servers**, and then select **Next**.

+1. On the **Select Group Members** blade, expand the computer, and then select either **BMR** or **system state**.

+1. On the **Select Data Protection Method** blade, choose how to handle short-term backup and long-term backup.

+1. On the **Select Short-Term Goals** blade, choose how to back up to short-term storage on disk:

+1. If you want to store data on tape for long-term storage, then on the **Specify Long-Term Goals** blade, choose how long to keep tape data (1 to 99 years).

+ 1. On the **Select Tape and Library Details** blade, select the tape and library to use. Also choose whether data should be compressed and encrypted.

+1. On the **Review Disk Allocation** blade, review the storage pool disk space that's available for the protection group.

+1. On the **Choose Replica Creation Method** blade, select how to handle the initial full-data replication.

+1. On the **Choose Consistency Check Options** blade, select how to automate consistency checks.

+1. If you chose to back up to the cloud by using Azure Backup, on the **Specify Online Protection Data** blade, select the workloads that you want to back up to Azure.

+1. On the **Specify Online Backup Schedule** blade, select how often to incrementally back up to Azure.

+1. On the **Specify Online Retention Policy** blade, select how the recovery points that are created from the daily, weekly, monthly, and yearly backups are kept in Azure.

+1. On the **Choose Online Replication** blade, select how the initial full replication of data occurs.

+1. On the **Summary** blade, review your settings. After you select **Create Group**, initial replication of the data occurs. When the data replication finishes, on the **Status** blade, the protection group status is **OK**. Backups then happen according to the protection group settings.

+To run recovery on the Backup Server computer, follow these steps:

+1. On the **Recovery** blade, find the computer that you want to recover. Then select **Bare Metal Recovery**.

+1. On the **Select Recovery Type** blade, select **Copy to a network folder**.

+1. On the **Specify Destination** blade, select the destination for the copied data.

+1. On the **Specify Recovery Options** blade, select the security settings. Then select whether to use storage area network (SAN)-based hardware snapshots, for quicker recovery. This option is available only if:

+1. On the **Confirmation** blade, select **Recover**.

+1. On the first blade, verify the settings for language and locale. On the **Install** blade, select **Repair your computer**.

+1. On the **System Recovery Options** blade, select **Restore your computer using a system image that you created earlier**.

+1. On the **Select a system image backup** blade, select **Select a system image** > **Advanced** > **Search for a system image on the network**. If a warning appears, select **Yes**. Go to the share path, enter the credentials, and then select the recovery point. The system scans for specific backups that are available in that recovery point. Select the recovery point that you want to use.

+1. On the **Choose how to restore the backup** blade, select **Format and repartition disks**. On the next blade, verify the settings.

+1. On the **Select Recovery Type** blade, select **Copy to a network folder**.

+1. On the **Specify Destination** blade, select where to copy the data.

+1. On the **Specify Recovery Options** blade, select the security settings. Then select whether to use SAN-based hardware snapshots, for quicker recovery. This option is available only if:

+1. On the **Confirmation** blade, select **Recover**.

+1. Select **Another Server**, select the **Specify Location Type** blade, and then select **Remote shared folder**. Enter the path to the folder that contains the recovery point.

+1. On the **Select Recovery Type** blade, select **System state**.

+1. On the **Select Location for System State Recovery** blade, select **Original Location**.

+1. On the **Confirmation** blade, select **Recover**.

+# [Vaulted backup (preview)](#tab/vaulted-backup)

+ Title: Monitoring data reference for Azure Batch

+description: This article contains important reference material you need when you monitor Azure Batch.

+# Azure Batch monitoring data reference

+<!-- Intro. Required. -->

+See [Monitor Azure Batch](monitor-batch.md) for details on the data you can collect for Azure Batch and how to use it.

+### Supported metrics for Microsoft.Batch/batchaccounts

+The following table lists the metrics available for the Microsoft.Batch/batchaccounts resource type.

+- poolId

+- jobId

+### Supported resource logs for Microsoft.Batch/batchaccounts

+### Service log events

+Batch service logs contain events emitted by the Batch service during the lifetime of an individual Batch resource, such as a pool or task. The Batch service emits the following log events:

+- [Pool create](batch-pool-create-event.md)

+- [Pool delete start](batch-pool-delete-start-event.md)

+- [Pool delete complete](batch-pool-delete-complete-event.md)

+- [Pool resize start](batch-pool-resize-start-event.md)

+- [Pool resize complete](batch-pool-resize-complete-event.md)

+- [Pool autoscale](batch-pool-autoscale-event.md)

+- [Task start](batch-task-start-event.md)

+- [Task complete](batch-task-complete-event.md)

+- [Task fail](batch-task-fail-event.md)

+- [Task schedule fail](batch-task-schedule-fail-event.md)

+Each event emitted by Batch is logged in JSON format. The following example shows the body of a sample **pool create event**:

+```json

+{

+ "id": "myPool1",

+ "displayName": "Production Pool",

+ "vmSize": "Standard_F1s",

+ "imageType": "VirtualMachineConfiguration",

+ "cloudServiceConfiguration": {

+ "osFamily": "3",

+ "targetOsVersion": "*"

+ },

+ "networkConfiguration": {

+ "subnetId": " "

+ },

+ "virtualMachineConfiguration": {

+ "imageReference": {

+ "publisher": " ",

+ "offer": " ",

+ "sku": " ",

+ "version": " "

+ },

+ "nodeAgentId": " "

+ },

+ "resizeTimeout": "300000",

+ "targetDedicatedNodes": 2,

+ "targetLowPriorityNodes": 2,

+ "taskSlotsPerNode": 1,

+ "vmFillType": "Spread",

+ "enableAutoScale": false,

+ "enableInterNodeCommunication": false,

+ "isAutoPool": false

+}

+```

+### Batch Accounts

+microsoft.batch/batchaccounts

+- [AzureActivity](/azure/azure-monitor/reference/tables/AzureActivity#columns)

+- [AzureMetrics](/azure/azure-monitor/reference/tables/AzureMetrics#columns)

+- [AzureDiagnostics](/azure/azure-monitor/reference/tables/AzureDiagnostics#columns)

+- [Microsoft.Batch resource provider operations](/azure/role-based-access-control/permissions/compute#microsoftbatch)

+## Related content

+- See [Monitor Batch](monitor-batch.md) for a description of monitoring Batch.

+- See [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for details on monitoring Azure resources.

+- Learn about the [Batch APIs and tools](batch-apis-tools.md) available for building Batch solutions.

+ Title: Monitor Azure Batch

+description: Start here to learn how to monitor Azure Batch.

+# Monitor Azure Batch

+For more information about the resource types for Batch, see [Batch monitoring data reference](monitor-batch-reference.md).

+### Access diagnostics logs in storage

+If you [archive Batch diagnostic logs in a storage account](/azure/azure-monitor/essentials/resource-logs#send-to-azure-storage), a storage container is created in the storage account as soon as a related event occurs. Blobs are created according to the following naming pattern:

+```json

+insights-{log category name}/resourceId=/SUBSCRIPTIONS/{subscription ID}/

+RESOURCEGROUPS/{resource group name}/PROVIDERS/MICROSOFT.BATCH/

+BATCHACCOUNTS/{Batch account name}/y={four-digit numeric year}/

+m={two-digit numeric month}/d={two-digit numeric day}/

+h={two-digit 24-hour clock hour}/m=00/PT1H.json

+```

+For example:

+```json

+insights-metrics-pt1m/resourceId=/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/

+RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.BATCH/

+BATCHACCOUNTS/MYBATCHACCOUNT/y=2018/m=03/d=05/h=22/m=00/PT1H.json

+```

+Each *PT1H.json* blob file contains JSON-formatted events that occurred within the hour specified in the blob URL (for example, `h=12`). During the present hour, events are appended to the *PT1H.json* file as they occur. The minute value (`m=00`) is always `00`, since diagnostic log events are broken into individual blobs per hour. All times are in UTC.

+The following example shows a `PoolResizeCompleteEvent` entry in a *PT1H.json* log file. The entry includes information about the current and target number of dedicated and low-priority nodes and the start and end time of the operation.

+```json

+{ "Tenant": "65298bc2729a4c93b11c00ad7e660501", "time": "2019-08-22T20:59:13.5698778Z", "resourceId": "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.BATCH/BATCHACCOUNTS/MYBATCHACCOUNT/", "category": "ServiceLog", "operationName": "PoolResizeCompleteEvent", "operationVersion": "2017-06-01", "properties": {"id":"MYPOOLID","nodeDeallocationOption":"Requeue","currentDedicatedNodes":10,"targetDedicatedNodes":100,"currentLowPriorityNodes":0,"targetLowPriorityNodes":0,"enableAutoScale":false,"isAutoPool":false,"startTime":"2019-08-22 20:50:59.522","endTime":"2019-08-22 20:59:12.489","resultCode":"Success","resultMessage":"The operation succeeded"}}

+```

+To access the logs in your storage account programmatically, use the [Storage APIs](/rest/api/storageservices).

+Examples of metrics in a Batch account are Pool Create Events, Low-Priority Node Count, and Task Complete Events. These metrics can help identify trends and can be used for data analysis.

+> [!NOTE]

+> Metrics emitted in the last 3 minutes might still be aggregating, so values might be underreported during this time frame. Metric delivery isn't guaranteed and might be affected by out-of-order delivery, data loss, or duplication.

+For a complete list of available metrics for Batch, see [Batch monitoring data reference](monitor-batch-reference.md#metrics).

+For the available resource log categories, their associated Log Analytics tables, and the logs schemas for Batch, see [Batch monitoring data reference](monitor-batch-reference.md#resource-logs).

+You must explicitly enable diagnostic settings for each Batch account you want to monitor.

+For the Batch service, you can collect the following logs:

+- **ServiceLog**: [Events emitted by the Batch service](monitor-batch-reference.md#service-log-events) during the lifetime of an individual resource such as a pool or task.

+- **AllMetrics**: Metrics at the Batch account level.

+The following screenshot shows an example diagnostic setting that sends **allLogs** and **AllMetrics** to a Log Analytics workspace.

+When you create an Azure Batch pool, you can install any of the following monitoring-related extensions on the compute nodes to collect and analyze data:

+- [Azure Monitor agent for Linux](/azure/azure-monitor/agents/azure-monitor-agent-manage)

+- [Azure Monitor agent for Windows](/azure/azure-monitor/agents/azure-monitor-agent-manage)

+- [Azure Diagnostics extension for Windows VMs](/azure/virtual-machines/windows/extensions-diagnostics)

+- [Azure Monitor Logs analytics and monitoring extension for Linux](/azure/virtual-machines/extensions/oms-linux)

+- [Azure Monitor Logs analytics and monitoring extension for Windows](/azure/virtual-machines/extensions/oms-windows)

+For a comparison of the different extensions and agents and the data they collect, see [Compare agents](/azure/azure-monitor/agents/agents-overview#compare-to-legacy-agents).

+For Batch accounts specifically, the activity log collects events related to account creation and deletion and key management.

+When you analyze count-based Batch metrics like Dedicated Core Count or Low-Priority Node Count, use the **Avg** aggregation. For event-based metrics like Pool Resize Complete Events, use the **Count** aggregation. Avoid using the **Sum** aggregation, which adds up the values of all data points received over the period of the chart.

+### Sample queries

+Here are a few sample log queries for Batch:

+Pool resizes: Lists resize times by pool and result code (success or failure):

+```kusto

+AzureDiagnostics

+| where OperationName=="PoolResizeCompleteEvent"

+| summarize operationTimes=make_list(startTime_s) by poolName=id_s, resultCode=resultCode_s

+```

+Task durations: Gives the elapsed time of tasks in seconds, from task start to task complete.

+```kusto

+AzureDiagnostics

+| where OperationName=="TaskCompleteEvent"

+| extend taskId=id_s, ElapsedTime=datetime_diff('second', executionInfo_endTime_t, executionInfo_startTime_t) // For longer running tasks, consider changing 'second' to 'minute' or 'hour'

+| summarize taskList=make_list(taskId) by ElapsedTime

+```

+Failed tasks per job: Lists failed tasks by parent job.

+```kusto

+AzureDiagnostics

+| where OperationName=="TaskFailEvent"

+| summarize failedTaskList=make_list(id_s) by jobId=jobId_s, ResourceId

+```

+### Batch alert rules

+Because metric delivery can be subject to inconsistencies such as out-of-order delivery, data loss, or duplication, you should avoid alerts that trigger on a single data point. Instead, use thresholds to account for these inconsistencies over a period of time.

+For example, you might want to configure a metric alert when your low priority core count falls to a certain level. You could then use this alert to adjust the composition of your pools. For best results, set a period of 10 or more minutes where the alert triggers if the average low priority core count falls lower than the threshold value for the entire period. This time period allows for metrics to aggregate so that you get more accurate results.

+The following table lists some alert rule triggers for Batch. These alert rules are just examples. You can set alerts for any metric, log entry, or activity log entry listed in the [Batch monitoring data reference](monitor-batch-reference.md).

+| Alert type | Condition | Description |

+|:|:|:|

+| Metric | Unusable node count | Whenever the Unusable Node Count is greater than 0 |

+| Metric | Task Fail Events | Whenever the total Task Fail Events is greater than dynamic threshold |

+## Other Batch monitoring options

+[Batch Explorer](https://github.com/Azure/BatchExplorer) is a free, rich-featured, standalone client tool to help create, debug, and monitor Azure Batch applications. You can use [Azure Batch Insights](https://github.com/Azure/batch-insights) with Batch Explorer to get system statistics for your Batch nodes, such as virtual machine (VM) performance counters.

+In your Batch applications, you can use the [Batch .NET library](/dotnet/api/microsoft.azure.batch) to monitor or query the status of your resources including jobs, tasks, nodes, and pools. For example:

+- Monitor the [task state](/rest/api/batchservice/task/list#taskstate).

+- Monitor the [node state](/rest/api/batchservice/computenode/list#computenodestate).

+- Monitor the [pool state](/rest/api/batchservice/pool/get#poolstate).

+- Monitor [pool usage in the account](/rest/api/batchservice/pool/listusagemetrics).

+- Count [pool nodes by state](/rest/api/batchservice/account/listpoolnodecounts).

+You can use the Batch APIs to create list queries for Batch jobs, tasks, compute nodes, and other resources. For more information about how to filter list queries, see [Create queries to list Batch resources efficiently](batch-efficient-list-queries.md).

+Or, instead of potentially time-consuming list queries that return detailed information about large collections of tasks or nodes, you can use the [Get Task Counts](/rest/api/batchservice/job/gettaskcounts) and [List Pool Node Counts](/rest/api/batchservice/account/listpoolnodecounts) operations to get counts for Batch tasks and compute nodes. For more information, see [Monitor Batch solutions by counting tasks and nodes by state](batch-get-resource-counts.md).

+You can integrate Application Insights with your Azure Batch applications to instrument your code with custom metrics and tracing. For a detailed walkthrough of how to add Application Insights to a Batch .NET solution, instrument application code, monitor the application in the Azure portal, and build custom dashboards, see [Monitor and debug an Azure Batch .NET application with Application Insights](monitor-application-insights.md) and accompanying [code sample](https://github.com/Azure/azure-batch-samples/tree/master/CSharp/ArticleProjects/ApplicationInsights).

+## Related content

+- See [Batch monitoring data reference](monitor-batch-reference.md) for a reference of the metrics, logs, and other important values created for Batch.

+- See [Monitoring Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for general details on monitoring Azure resources.

+- Learn about the [Batch APIs and tools](batch-apis-tools.md) available for building Batch solutions.

+ You can also query information for your backup and replication policies at no additional cost using Azure Resource Graph (ARG). ARG is an Azure service designed to extend Azure Resource Management. It aims to provide efficient resource exploration with the ability to query at scale across a given set of subscriptions.

+ To get started with querying information for your backup and replication policies using ARG, you can use the sample query provided by selecting **Open query**.

+ :::image type="content" source="./media/manage-protection-policy/query-for-backup-and-replication-policies.png" alt-text="Screenshot shows how to check for queries to view backup and replication policies." lightbox="./media/manage-protection-policy/query-for-backup-and-replication-policies.png":::

+You can also query information for your vaults at no additional cost using Azure Resource Graph (ARG). ARG is an Azure service designed to extend Azure Resource Management. It aims to provide efficient resource exploration with the ability to query at scale across a given set of subscriptions.

+To get started with querying information for your vaults using ARG, you can use the sample query provided by selecting **Open query**.

+You can also query information on your protectable Azure resources at no additional cost using Azure Resource Graph (ARG). ARG is an Azure service designed to extend Azure Resource Management. It aims to provide efficient resource exploration with the ability to query at scale across a given set of subscriptions.

+To get started with querying your protectable Azure resources using ARG, you can use the sample query provided by selecting **Open query**.

+By default, only Azure Virtual machines are shown in the **Protectable resources** list. You can change the filters to view other resources.

+You can also query information on protection for your resources at no additional cost using Azure Resource Graph (ARG). ARG is an Azure service designed to extend Azure Resource Management. It aims to provide efficient resource exploration with the ability to query at scale across a given set of subscriptions.

+To get started with querying information on protection for your resources using ARG, you can use the sample query provided, by selecting **Open query**.

+This tutorial shows how to enable the HTTPS protocol for a custom domain associated with an Azure CDN endpoint.

+The HTTPS protocol on your custom domain (for example, `https://www.contoso.com`), ensures your sensitive data is delivered securely via TLS/SSL. When your web browser is connected via HTTPS, the browser validates the web site's certificate. The browser verifies it's issued by a legitimate certificate authority. This process provides security and protects your web applications from attacks.

+Azure CDN supports HTTPS on a CDN endpoint hostname, by default. For example, if you create a CDN endpoint (such as `https://contoso.azureedge.net`), HTTPS is automatically enabled.

+If the custom domain is already mapped to the CDN endpoint, no further action is needed. Azure CDN processes the steps and completes your request automatically.

+You can use your own certificate to enable the HTTPS feature. This process is done through an integration with Azure Key Vault, which allows you to store your certificates securely. Azure CDN uses this secure mechanism to get your certificate and it requires a few extra steps. 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 nonallowed CA, your request is rejected. If a certificate without complete chain is presented, requests, which involve that certificate aren't guaranteed to work as expected. For Azure CDN from Edgio, any valid CA is accepted.

+If your CNAME record is in the correct format, DigiCert automatically verifies your custom domain name and creates a certificate for your domain. DigitCert doesn't send you a verification email and you don't need to approve your request. The certificate is valid for one year and will be autorenewed before it expires. Continue to [Wait for propagation](#wait-for-propagation).

+The following table shows the operation progress that occurs when you enable HTTPS. After you enable HTTPS, four operation steps appear in the custom domain dialog. As each step becomes active, other substep details appear under the step as it progresses. Not all of these substeps occur. After a step successfully completes, a green check mark appears next to it.

+| 2 Domain validation | Domain is automatically validated if it's CNAME mapped to the CDN Endpoint. Otherwise, a verification request is sent to the email listed in your domain's registration record (WHOIS registrant).|

+#### Certificate auto rotation with Azure CDN from Edgio

+Managed certificates from Azure Key Vault can utilize the certificate autorotate feature, allowing Azure CDN from Edgio to automatically retrieve updated certificates and propagate them to the Edgio CDN platform. To enable this feature:

+1. Register Azure CDN as an application within your Microsoft Entra ID.

+1. Authorize the Azure CDN service to access the secrets in your Key Vault. Navigate to "Access policies" within your Key Vault to add a new policy, then grant the **Microsoft.AzureFrontDoor-Cdn** service principal a **Get secrets** permission.

+1. Set the certificate version to **Latest** under the **Certificate management type** within the **Custom domain** menu. If a specific version of the certificate is selected, manual updates are required.

+> [!NOTE]

+> * Be aware that it can take up to 24 hours for the certificate auto-rotate to fully complete the propagation of the new certificate.

+> * If a certificate is utilized to cover multiple custom domains, it is imperative to enable certificate auto-rotate on all the custom domains sharing this certificate to ensure correct operation. Failure to do so may result in the Edgio platform serving an incorrect version of the certificate for the custom domain that does not have this feature enabled."

+ Your existing domains are gradually migrated to single certificate in the upcoming months if Microsoft analyzes that only SNI client requests are made to your application.

+ Title: Deploy Azure Cloud Services (extended support) - Azure portal

+# Deploy Azure Cloud Services (extended support) using the Azure portal

+| [`RouterWorkerUpdated`](#microsoftcommunicationrouterworkerupdated) | `Worker` | One of the following worker properties has been updated: `AvailableForOffers`, `TotalCapacity`, `QueueAssignments`, `ChannelConfigurations`, `Labels`, `Tags` |

+### Microsoft.Communication.RouterWorkerUpdated

+[Back to Event Catalog](#events-catalog)

+```json

+{

+ "id": "1027db4a-17fe-4a7f-ae67-276c3120a29f",

+ "topic": "/subscriptions/{subscription-id}/resourceGroups/{group-name}/providers/Microsoft.Communication/communicationServices/{communication-services-resource-name}",

+ "subject": "worker/{worker-id}",

+ "data": {

+ "workerId": "worker3",

+ "availableForOffers": true,

+ "totalCapacity": 100,

+ "queueAssignments": [

+ {

+ "id": "MyQueueId2",

+ "name": "Queue 3",

+ "labels": {

+ "Language": "en",

+ "Product": "Office",

+ "Geo": "NA"

+ }

+ }

+ ],

+ "labels": {

+ "x": "111",

+ "y": "111"

+ },

+ "channelConfigurations": [

+ {

+ "channelId": "FooVoiceChannelId",

+ "capacityCostPerJob": 10,

+ "maxNumberOfJobs": 5

+ }

+ ],

+ "tags": {

+ "Locale": "en-us",

+ "Segment": "Enterprise",

+ "Token": "FooToken"

+ },

+ "updatedWorkerProperties": [

+ "TotalCapacity",

+ "Labels",

+ "Tags",

+ "ChannelConfigurations",

+ "AvailableForOffers",

+ "QueueAssignments"

+ ]

+ },

+ "eventType": "Microsoft.Communication.RouterWorkerUpdated",

+ "dataVersion": "1.0",

+ "metadataVersion": "1",

+ "eventTime": "2022-02-17T00:55:25.1736293Z"

+}

+```

+#### Attribute list

+| Attribute | Type | Nullable | Description | Notes |

+|: |:--:|:-:|-|-|

+| workerId | `string` | ❌ |

+| totalCapacity | `int` | ❌ |

+| queueAssignments | `List<QueueDetails>` | ❌ |

+| labels | `Dictionary<string, object>` | ✔️ | | Based on user input

+| channelConfigurations| `List<ChannelConfiguration>` | ❌ |

+| tags | `Dictionary<string, object>` | ✔️ | | Based on user input

+| updatedWorkerProperties | `List<UpdateWorkerProperty>` | ❌ | Worker Properties updated including AvailableForOffers, QueueAssignments, ChannelConfigurations, TotalCapacity, Labels, and Tags

+### UpdatedWorkerProperty

+```csharp

+public enum UpdatedWorkerProperty

+{

+ AvailableForOffers,

+ Capacity,

+ QueueAssignments,

+ Labels,

+ Tags,

+ ChannelConfigurations

+}

+```

+ Title: Certificates in Azure Container Apps

+description: Learn the different options available to using and managing secure certificates in Azure Container Apps.

+# Certificates in Azure Container Apps

+You can add digital security certificates to secure custom DNS names in Azure Container Apps to support secure communication among your apps.

+## Options

+The following table lists the options available to add certificates in Container Apps:

+| Option | Description |

+|||

+| [Create a free Azure Container Apps managed certificate](./custom-domains-managed-certificates.md) | A private certificate that's free of charge and easy to use if you just need to secure your custom domain in Container Apps. |

+| Import a certificate from Key Vault | Useful if you use [Azure Key Vault](../key-vault/index.yml) to manage your [PKCS12 certificates](https://wikipedia.org/wiki/PKCS_12). |

+| [Upload a private certificate](./custom-domains-certificates.md) | You can upload a private certificate if you already have one. |

+## Next steps

+> [!div class="nextstepaction"]

+> [Set up custom domain with existing certificate](custom-domains-certificates.md)

+ Title: Collect and read OpenTelemetry data in Azure Container Apps (preview)

+description: Learn to record and query data collected using OpenTelemetry in Azure Container Apps.

+# Collect and read OpenTelemetry data in Azure Container Apps (preview)

+Using an [OpenTelemetry](https://opentelemetry.io/) data agent with your Azure Container Apps environment, you can choose to send observability data in an OpenTelemetry format by:

+- Piping data from an agent into a desired endpoint. Destination options include Azure Monitor Application Insights, Datadog, and any OpenTelemetry Protocol (OTLP)-compatible endpoint.

+- Easily changing destination endpoints without having to reconfigure how they emit data, and without having to manually run an OpenTelemetry agent.

+This article shows you how to set up and configure an OpenTelemetry agent for your container app.

+## Configure an OpenTelemetry agent

+OpenTelemetry agents live within your container app environment. You configure agent settings via an ARM template or Bicep calls to the environment, or through the CLI.

+Each endpoint type (Azure Monitor Application Insights, DataDog, and OTLP) has specific configuration requirements.

+## Prerequisites

+Enabling the managed OpenTelemetry agent to your environment doesn't automatically mean the agent collects data. Agents only send data based on your configuration settings and instrumenting your code correctly.

+### Configure source code

+Prepare your application to collect data by installing the [OpenTelemetry SDK](https://opentelemetry.io/ecosystem/integrations/) and follow the OpenTelemetry guidelines to instrument [metrics](https://opentelemetry.io/docs/concepts/signals/logs/), [logs](https://opentelemetry.io/docs/concepts/signals/metrics), or [traces](https://opentelemetry.io/docs/concepts/signals/traces/).

+### Initialize endpoints

+Before you can send data to a collection destination, you first need to create an instance of the destination service. For example, if you want to send data to Azure Monitor Application Insights, you need to create an Application Insights instance ahead of time.

+The managed OpenTelemetry agent accepts the following destinations:

+- Azure Monitor Application Insights

+- Datadog

+- Any OTLP endpoint (For example: New Relic or Honeycomb)

+The following table shows you what type of data you can send to each destination:

+| Destination | Logs | Metrics | Traces |

+||||--|

+| [Azure App Insights](/azure/azure-monitor/app/app-insights-overview) | Yes | Yes | Yes |

+| [Datadog](https://datadoghq.com/) | No | Yes | Yes |

+| [OpenTelemetry](https://opentelemetry.io/) protocol (OTLP) configured endpoint | Yes | Yes | Yes |

+## Azure Monitor Application Insights

+The only configuration detail required from Application Insights is the connection string. Once you have the connection string, you can configure the agent via your container app's ARM template or with Azure CLI commands.

+# [ARM template](#tab/arm)

+Before you deploy this template, replace placeholders surrounded by `<>` with your values.

+```json

+{

+ ...

+ "properties": {

+ "appInsightsConfiguration ": {ΓÇ»

+ "connectionString": "<YOUR_APP_INSIGHTS_CONNECTION_STRING>"

+ }

+ "openTelemetryConfiguration": {

+ ...

+ "tracesConfiguration":{

+ "destinations": ["appInsights"]

+ },

+ "logsConfiguration": {

+ "destinations": ["apInsights"]

+ }

+ }

+ }

+}

+```

+# [Azure CLI](#tab/azure-cli)

+Before you run this command, replace placeholders surrounded by `<>` with your values.

+```azurecli

+az containerapp env telemetry app-insights set \

+ --connection-string <YOUR_APP_INSIGHTS_CONNECTION_STRING> \

+ --EnableOpenTelemetryTraces true \

+ --EnableOpenTelemetryLogs true

+```

+## Datadog

+The Datadog agent configuration requires a value for `site` and `key` from your Datadog instance. Gather these values from your Datadog instance according to this table:

+| Datadog agent property | Container Apps configuration property |

+|||

+| `DD_SITE` | `site` |

+| `DD_API_KEY` | `key` |

+Once you have these configuration details, you can configure the agent via your container app's ARM template or with Azure CLI commands.

+# [ARM template](#tab/arm)

+Before you deploy this template, replace placeholders surrounded by `<>` with your values.

+```json

+{

+ ...

+ "properties": {

+ ...

+ "openTelemetryConfiguration": {

+ ...

+ "destinationsConfiguration":{

+ ...

+ "dataDogConfiguration":{

+ "site": "<YOUR_DATADOG_SUBDOMAIN>.datadoghq.com",

+ "key": "<YOUR_DATADOG_KEY>"

+ }

+ },

+ "tracesConfiguration":{

+ "destinations": ["dataDog"]

+ },

+ "metricsConfiguration": {

+ "destinations": ["dataDog"]

+ }

+ }

+ }

+}

+```

+# [Azure CLI](#tab/azure-cli)

+Before you run this command, replace placeholders surrounded by `<>` with your values.

+```azurecli

+az containerapp env telemetry data-dog set \

+ --site "<YOUR_DATADOG_SUBDOMAIN>.datadoghq.com" \

+ --key <YOUR_DATADOG_KEY> \

+ --EnableOpenTelemetryTraces true \

+ --EnableOpenTelemetryMetrics true

+```

+## OTLP endpoint

+An OpenTelemetry protocol (OTLP) endpoint is a telemetry data destination that consumes OpenTelemetry data. In your application configuration, you can add multiple OTLP endpoints. The following example adds two endpoints and sends the following data to these endpoints.

+| Endpoint name | Data sent to endpoint |

+|||

+| `oltp1` | Metrics and/or traces |

+| `oltp2` | Logs and/or traces |

+While you can set up as many OTLP-configured endpoints as you like, each endpoint must have a distinct name.

+# [ARM template](#tab/arm)

+```json

+{

+ "properties": {

+ "appInsightsConfiguration": {},

+ "openTelemetryConfiguration": {

+ "destinationsConfiguration":{

+ "otlpConfiguration": [

+ {

+ "name": "otlp1",

+ "endpoint": "ENDPOINT_URL_1",

+ "insecure": false,

+ "headers": "api-key-1=key"

+ },

+ {

+ "name": "otlp2",

+ "endpoint": "ENDPOINT_URL_2",

+ "insecure": true

+ }

+ ]

+ },

+ "logsConfiguration": {

+ "destinations": ["otlp2"]

+ },

+ "tracesConfiguration":{

+ "destinations": ["otlp1", "otlp2"]

+ },

+ "metricsConfiguration": {

+ "destinations": ["otlp1"]

+ }

+ }

+ }

+}

+```

+# [Azure CLI](#tab/azure-cli)

+```azurecli

+az containerap env telemetry otlp add \

+ --name "otlp1"

+ --endpoint "ENDPOINT_URL_1" \

+ --insecure false \

+ --headers "api-key-1=key" \

+ --EnableOpenTelemetryTraces true \

+ --EnableOpenTelemetryMetrics true

+az containerap env telemetry otlp add \

+ --name "otlp2"

+ --endpoint "ENDPOINT_URL_2" \

+ --insecure true \

+ --EnableOpenTelemetryTraces true \

+ --EnableOpenTelemetryLogs true

+```

+| Name | Description |

+|||

+| `name` | A name you select to identify your OTLP-configured endpoint. |

+| `endpoint` | The URL of the destination that receives collected data. |

+| `insecure` | Default true. Defines whether to enable client transport security for the exporter's gRPC connection. If false, the `headers` parameter is required. |

+| `headers` | Space-separated values, in 'key=value' format, that provide required information for the OTLP endpoints' security. Example: `"api-key=key other-config-value=value"`. |

+## Configure Data Destinations

+To configure an agent, use the `destinations` array to define which agents your application sends data. Valid keys are either `appInsights`, `dataDog`, or the name of your custom OTLP endpoint. You can control how an agent behaves based off data type and endpoint-related options.

+### By data type

+| Option | Example |

+|||

+| Select a data type. | You can configure logs, metrics, and/or traces individually. |

+| Enable or disable any data type. | You can choose to send only traces and no other data. |

+| Send one data type to multiple endpoints. | You can send logs to both DataDog and an OTLP-configured endpoint. |

+| Send different data types to different locations. | You can send traces to an OTLP endpoint and metrics to DataDog. |

+| Disable sending all data types. | You can choose to not send any data through the OpenTelemetry agent. |

+### By endpoint

+- You can only set up one Application Insights and Datadog endpoint each at a time.

+- While you can define more than one OTLP-configured endpoint, each one must have a distinct name.

+The following example shows how to use an OTLP endpoint named `customDashboard`. It sends:

+- traces to app insights and `customDashboard`

+- logs to app insights and `customDashboard`

+- metrics to DataDog and `customDashboard`

+```json

+{

+ ...

+ "properties": {

+ ...

+ "openTelemetryConfiguration": {

+ ...

+ "tracesConfiguration": {

+ "destinations": [

+ "appInsights",

+ "customDashboard"

+ ]

+ },

+ "logsConfiguration": {

+ "destinations": [

+ "appInsights",

+ "customDashboard"

+ ]

+ },

+ "metricsConfiguration": {

+ "destinations": [

+ "dataDog",

+ "customDashboard"

+ ]

+ }

+ }

+ }

+}

+## Example OpenTelemetry configuration

+The following example ARM template shows how you might configure your container app to collect telemetry data using Azure Monitor Application Insights, Datadog, and with a custom OTLP agent named `customDashboard`.

+Before you deploy this template, replace placeholders surrounded by `<>` with your values.

+```json

+{

+ "location": "eastus",

+ "properties": {

+ "appInsightsConfiguration": {

+ "connectionString": "<APP_INSIGHTS_CONNECTION_STRING>"

+ },

+ "openTelemetryConfiguration": {

+ "destinationsConfiguration": {

+ "dataDogConfiguration": {

+ "site": "datadoghq.com",

+ "key": "<YOUR_DATADOG_KEY>"

+ },

+ "otlpConfigurations": [

+ {

+ "name": "customDashboard",

+ "endpoint": "<OTLP_ENDPOINT_URL>",

+ "insecure": true

+ }

+ ]

+ },

+ "tracesConfiguration": {

+ "destinations": [

+ "appInsights",

+ "customDashboard"

+ ]

+ },

+ "logsConfiguration": {

+ "destinations": [

+ "appInsights",

+ "customDashboard"

+ ]

+ },

+ "metricsConfiguration": {

+ "destinations": [

+ "dataDog",

+ "customDashboard"

+ ]

+ }

+ }

+ }

+}

+```

+## Environment variables

+The OpenTelemetry agent automatically injects a set of environment variables into your application at runtime.

+The first two environment variables follow standard OpenTelemetry exporter configuration and are used in OTLP standard software development kits. If you explicitly set the environment variable in the container app specification, your value overwrites the automatically injected value.

+Learn about the OTLP exporter configuration see, [OTLP Exporter Configuration](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/).

+| Name | Description |

+|||

+| `OTEL_EXPORTER_OTLP_ENDPOINT` | A base endpoint URL for any signal type, with an optionally specified port number. This setting is helpful when youΓÇÖre sending more than one signal to the same endpoint and want one environment variable to control the endpoint. Example: `http://otel.service.k8se-apps:4317/` |

+| `OTEL_EXPORTER_OTLP_PROTOCOL` | Specifies the OTLP transport protocol used for all telemetry data. The managed agent only supports `grpc`. Value: `grpc`. |

+The other three environment variables are specific to Azure Container Apps, and are always injected. These variables hold agentΓÇÖs endpoint URLs for each specific data type (logs, metrics, traces).

+These variables are only necessary if you're using both the managed OpenTelemetry agent and another OpenTelemetry agent. Using these variables gives you control over how to route data between the different OpenTelemetry agents.

+| Name | Description | Example |

+||||

+| `CONTAINERAPP_OTEL_TRACING_GRPC_ENDPOINT` | Endpoint URL for trace data only. | `http://otel.service.k8se-apps:43178/v1/traces/` |

+| `CONTAINERAPP_OTEL_LOGGING_GRPC_ENDPOINT` | Endpoint URL for log data only. | `http://otel.service.k8se-apps:43178/v1/logs/ ` |

+| `CONTAINERAPP_OTEL_METRIC_GRPC_ENDPOINT` | Endpoint URL for metric data only. | `http://otel.service.k8se-apps:43178/v1/metrics/` |

+## OpenTelemetry agent costs

+You are [billed](./billing.md) for the underlying compute of the agent.

+See the destination service for their billing structure and terms. For example, if you send data to both Azure Monitor Application Insights and Datadog, you're responsible for the charges applied by both services.

+## Known limitations

+- OpenTelemetry agents are in preview.

+- System data, such as system logs or Container Apps standard metrics, isn't available to be sent to the OpenTelemetry agent.

+- The Application Insights endpoint doesn't accept metrics.

+- The Datadog endpoint doesn't accept logs.

+## Next steps

+> [!div class="nextstepaction"]

+> [Learn about monitoring and health](observability.md)

+| **I'm new to containers**| Start here if you have yet to build your first container but are curious how containers can serve your development needs. | [Learn more about containers](start-containers.md) |

+| **I'm using serverless containers** | Container Apps provides automatic scaling, reduces operational complexity, and allows you to focus on your application rather than infrastructure.<br><br>Start here if you're interested in the management, scalability, and pay-per-use features of cloud computing. | [Learn more about serverless containers](start-serverless-containers.md) |

+- [**Generous quotas**](quotas.md), which can be overridden to increase limits on a per-account basis.

+Companies that want a local presence or a hot backup choose to run services from multiple Azure regions. As a best practice, placing a container registry in each region where images are run allows network-close operations, enabling fast, reliable image layer transfers. Geo-replication enables an Azure container registry to function as a single registry, serving multiple regions with multi-primary regional registries.

+> * If you need to maintain copies of container images in more than one Azure container registry, Azure Container Registry also supports [image import](container-registry-import-images.md). For example, in a DevOps workflow, you can import an image from a development registry to a production registry without needing to use Docker commands.

+* The user requires the following permissions (at the registry level) to create/delete replications:

+Contoso runs a public presence website located across the US, Canada, and Europe. To serve these markets with local and network-close content, Contoso runs [Azure Kubernetes Service](../aks/index.yml) (AKS) clusters in West US, East US, Canada Central, and West Europe. The website application, deployed as a Docker image, utilizes the same code and image across all regions. Content local to that region is retrieved from a database, which is provisioned uniquely in each region. Each regional deployment has its unique configuration for resources like the local database.

+The development team is located in Seattle, WA, and utilizes the West US data center.

+The geo-replication feature of Azure Container Registry has the following benefits:

+* Push to a single registry while ACR automatically manages the geo-replication. ACR only replicates unique layers, reducing data transfer across regions.

+* For every push or pull image operation on a geo-replicated registry, Azure Traffic Manager in the background sends a request to the registry's closest location in the region to maintain network latency.

+* If the registry's home region becomes unavailable, you may be unable to carry out registry management operations, including configuring network rules, enabling availability zones, and managing replicas.

+1. Navigate to your Azure Container Registry and select **Replications**.

+1. Select the name of a replica and select **Delete**. Confirm that you want to delete the replica.

+In the preceding example, Contoso consolidated two registries down to one, adding replicas to East US, Canada Central, and West Europe. Contoso would pay four times Premium per month, with no additional configuration or management. Each region now pulls their images locally, improving performance and reliability without network egress fees from the West US to Canada and the East US.

+When creating a new registry replication for the primary registry enabled with Private Endpoint, we recommend validating that the User Identity has valid Private Endpoint creation permissions. Otherwise, the operation gets stuck in the provisioning state while creating the replication.

+1. If not already installed, install the `Azure.Data.Tables` package using `dotnet add package`.

+ dotnet add package Azure.Data.Tables

+description: Vector database

+Many AI-enhanced systems that emerged in 2023 use standalone vector databases that are distinct from "traditional" databases in their tech stacks. Instead of adding a separate vector database, you can use our integrated vector database when working with multi-modal data. By doing so, you avoid the extra cost of moving data to a separate database. Moreover, this architecture keeps your vector embeddings and original data together, and you can better achieve data consistency, scale, and performance. The latter reason is why OpenAI built its ChatGPT service on top of Azure Cosmos DB.

+Here's how to implement our integrated vector database, thereby taking advantage of its single-digit millisecond response times, automatic and instant scalability, and guaranteed speed at any scale:

+| **[Azure Cosmos DB for Mongo DB vCore](#how-to-implement-vector-database-functionalities-using-our-api-for-mongodb-vcore)** | Store your application data and vector embeddings together in a single MongoDB-compatible service featuring natively integrated vector database. |

+| **[Azure Cosmos DB for PostgreSQL](#how-to-implement-vector-database-functionalities-using-our-api-for-postgresql)** | Store your data and vectors together in a scalable PostgreSQL offering with natively integrated vector database. |

+| **[Azure Cosmos DB for NoSQL with Azure AI Search](#how-to-implement-vector-database-functionalities-using-our-nosql-api-and-ai-search)** | Augment your Azure Cosmos DB data with semantic and vector search capabilities of Azure AI Search. |

+In a vector database, embeddings are indexed and queried through [vector search](#vector-search) algorithms based on their vector distance or similarity. A robust mechanism is necessary to identify the most relevant data. Some well-known vector search algorithms include Hierarchical Navigable Small World (HNSW), Inverted File (IVF), DiskANN, etc.

+Besides the above functionalities of a typical vector database, our integrated vector database also converts the existing raw data in your account into embeddings and stores them as vectors. This way, you avoid the extra cost of moving data to a separate vector database. Moreover, this architecture keeps your vector embeddings and original data together, and you can better achieve data consistency, scale, and performance.

+## What are some vector database use cases?

+Vector databases are used in numerous domains and situations across analytical and generative AI, including natural language processing, video and image recognition, recommendation system, search, etc. For example, you can use a vector database to:

+- identify similar images, documents, and songs based on their contents, themes, sentiments, and styles

+- identify similar products based on their characteristics, features, and user groups

+- recommend contents, products, or services based on individuals' preferences

+- recommend contents, products, or services based on user groups' similarities

+- identify the best-fit potential options from a large pool of choices to meet complex requirements

+- identify data anomalies or fraudulent activities that are dissimilar from predominant or normal patterns

+- implement persistent memory for AI agents

+Besides these typical use cases for vector database, our integrated vector database is also an ideal solution for production-level LLM caching thanks to its low latency, high scalability, and high availability.

+It's especially popular to use vector databases to enable [retrieval-augmented generation (RAG)](#retrieval-augmented-generation) that harnesses LLMs and custom data or domain-specific information. This approach allows you to:

+- Generate contextually relevant and accurate responses to user prompts from AI models

+- Overcome LLMs' [tokens](#tokens) limits

+- Reduce the costs from frequent fine-tuning on updated data

+This process involves extracting pertinent information from a custom data source and integrating it into the model request through prompt engineering. Before sending a request to the LLM, the user input/query/request is also transformed into an embedding, and vector search techniques are employed to locate the most similar embeddings within the database. This technique enables the identification of the most relevant data records in the database. These retrieved records are then supplied as input to the LLM request using [prompt engineering](#prompts-and-prompt-engineering).

+Here are multiple ways to implement RAG on your data by using our vector database functionalities:

+## How to implement vector database functionalities using our API for MongoDB vCore

+## How to implement vector database functionalities using our API for PostgreSQL

+## How to implement vector database functionalities using our NoSQL API and AI Search

+## Related content

+- [Azure Cosmos DB for MongoDB vCore Integrated Vector Database](mongodb/vcore/vector-search.md)

+- [Azure PostgreSQL Server pgvector Extension](../postgresql/flexible-server/how-to-use-pgvector.md)

+- [Azure AI Search](../search/search-what-is-azure-search.md)

+- [Open Source Vector Database List](/semantic-kernel/memories/vector-db#available-connectors-to-vector-databases)

+ - **dags/**: For Apache Airflow directed acyclic graphs (dags) (required).

+ Title: Work with farm activities data in Azure Data Manager for Agriculture

+description: Learn how to integrate with data providers for farm activities and ingest data into Azure Data Manager for Agriculture.

+# Work with farm activities data in Azure Data Manager for Agriculture

+Data about farm activities is one of the most important ground-truth datasets in precision agriculture. These machine-generated reports preserve the record of exactly what happened and when. That record can help improve in-field practice and the downstream value-chain analytics.

+Azure Data Manager for Agriculture supports both:

+* **Summary data**: Entered as properties directly in the operation data item.

+* **Precision data**: Uploaded as an attachment file (for example, .shp, .dat, or .isoxml) and reference linked to the operation data item.

+New operation data can be pushed into the service via the APIs for operation and attachment creation. Or, if the desired source is in the supported list of original equipment manufacturer (OEM) connectors, data can be synced automatically from providers like Climate FieldView with an ingestion job for farm operations.

+Azure Data Manager for Agriculture supports a range of data about farm activities. For more information, see [What is Azure Data Manager for Agriculture?](/rest/api/data-manager-for-agri).

+## Integration with manufacturers of farm equipment

+Azure Data Manager for Agriculture fetches the associated data about farm activities (planting, application, tillage, and harvest) from the data provider (for example, Climate FieldView) by creating a data ingestion job for farm activities. For more information, see [Working with farm activities and activity data in Azure Data Manager for Agriculture](./how-to-ingest-and-egress-farm-operations-data.md).

+* [Test the Azure Data Manager for Agriculture REST APIs](/rest/api/data-manager-for-agri)

+description: Get information on the data model to organize your agriculture-related data.

+# Hierarchy model in Azure Data Manager for Agriculture

+To generate actionable insights, data related to growers, farms, and fields should be organized in a well-defined way. Firms that operate in the agriculture industry often perform longitudinal studies and need high-quality data to generate insights. Azure Data Manager for Agriculture organizes agronomic data in the following hierarchy.

+## Farm hierarchy

+### Party

+A party is the owner and custodian of any data related to a farm. You can think of a party as the legal entity that runs the business.

+The customer who sets up Azure Data Manager for Agriculture defines the party entity.

+Farms are logical entities. A farm is a collection of fields.

+Farms don't have any geometry associated with them. A farm entity helps you organize your growing operations. For example, Contoso Ltd. is the party that has farms in Oregon and Idaho.

+Fields denote a stable geometry that's generally agnostic to seasons and other temporal constructs. For example, a field could be the geometry denoted in government records.

+Fields are multipolygons. For example, a road might divide the farm into two or more parts.

+A seasonal field is the most important construct in the farming world. A seasonal field's definition includes:

+* Geometry

+* Season

+* Crop

+A seasonal field is:

+* Associated with a field or a farm.

+* A monocrop entity in Azure Data Manager for Agriculture. If farmers cultivate multiple crops simultaneously, they have to create one seasonal field per crop.

+* Associated with one season. If farmers cultivate across multiple seasons, they have to create one seasonal field per season.

+* A multipolygon. The same crop can be planted in various areas within the farm.

+The season represents the temporal aspect of farming. It's a function of local agronomic practices, procedures, and weather.

+A crop entity provides the phenotypic details of the planted crop.

+A crop product is the commercial variety (brand and product) of the planted seeds. A seasonal field can contain information about varieties of seeds planted in the same crop.

+* [Test the Azure Data Manager for Agriculture REST APIs](/rest/api/data-manager-for-agri)

+ Title: Ingest satellite data in Azure Data Manager for Agriculture

+description: Get step-by-step guidance on how to ingest satellite data.

+# Ingest satellite imagery in Azure Data Manager for Agriculture

+Satellite imagery is a foundational pillar of agriculture data. To support scalable ingestion of geometry-clipped imagery, Microsoft partnered with Sentinel Hub by Sinergise to provide a seamless bring your own license (BYOL) experience for Azure Data Manager for Agriculture. You can use this BYOL experience to manage your own costs. This capability helps you with storing your field-clipped historical and up-to-date imagery in the linked context of the relevant fields.

+* To search for and ingest imagery, you need a user account that has suitable subscription entitlement with [Sentinel Hub](https://www.sentinel-hub.com/pricing/).

+* Read the [Sinergise Sentinel Hub terms of service and privacy policy](https://www.sentinel-hub.com/tos/).

+* Have your `providerClientId` and `providerClientSecret` values ready.

+Using satellite data in Azure Data Manager for Agriculture involves the following steps:

+Because all ingested data is under a BYOL model, the cost of a job is transparent. Azure Data Manager for Agriculture offers built-in logging to provide transparency on processing unit (PU) consumption for calls to upstream partner Sentinel Hub. The information appears under the `SatelliteLogs` category of the [standard Azure Data Manager logging](how-to-set-up-audit-logs.md).

+## STAC search for available imagery

+Azure Data Manager for Agriculture supports the industry-standard [SpatioTemporal Asset Catalogs (STAC)](https://stacspec.org/en) search interface to find metadata on imagery in the Sentinel Hub collection before committing to downloading pixels. To do so, the search endpoint accepts a location in the form of a point, polygon, or multipolygon, plus a start and end date/time. Alternatively, if you already have the unique item ID, you can provide it as an array of up to five to retrieve those specific items directly.

+> To be consistent with STAC syntax, *feature ID* is renamed to *item ID* from the 2023-11-01-preview API version.

+>

+> If you provide an item ID, any location and time parameters in the request are ignored.

+## Single-tile source control

+Published tiles overlap space on the earth to ensure full spatial coverage. If the queried geometry lies in a space where more than one tile matches for a reasonable time frame, the provider automatically mosaics the returned image with selected pixels from the range of candidate tiles. The provider produces the best resulting image.

+In some cases, using more than one tile isn't desirable and traceability to a single tile source is preferred. To support this strict source control, Azure Data Manager for Agriculture supports specifying a single item ID in the ingest job.

+> This functionality is available only from the 2023-11-01-preview API version.

+>

+> If the geometry for a provided item ID has partial coverage (for example, the geometry spans more than one tile), the returned images reflect only the pixels that are present in the specified item's tile and result in a partial image.

+> [!IMPORTANT]

+> Reprojection functionality has changed from the 2023-11-01-preview API version, but it's immediately applicable to all versions. Older versions used a static conversion of 10 m * 10 m set at the equator. Imagery ingested before this release might have a difference in size from imagery ingested after this release.

+Azure Data Manager for Agriculture uses WGS84 (EPSG: 4326), a flat coordinate system. Sentinel-2 imagery is presented in UTM, a ground projection system that approximates the round earth.

+Translating between a flat image and a round earth involves an approximation translation. The accuracy of this translation is set to equal at the equator (10 m^2) and increases in error margin as the point in question moves away from the equator to the poles.

+For consistency, Azure Data Manager for Agriculture uses the following formula at 10 m^2 base for all Sentinel-2 calls:

+> Caching functionality is available only from the 2023-11-01-preview API version. Item caching is applicable only for retrieval that's based on item ID. For a typical geometry and time search, the returned items aren't cached.

+Azure Data Manager for Agriculture optimizes performance and costing of highly repeated calls to the same item. It caches recent STAC items retrieved by item ID for five days in the customer's instance and enables local retrieval.

+For the first call to the search endpoint, Azure Data Manager for Agriculture brokers the request and triggers a request to the upstream provider to retrieve the matching or intersecting data items. The request incurs any provider fees.

+Any subsequent search first directs to the cache for a match. If there's a match, data is served from the cache directly. This process doesn't result in a call to the upstream provider, so it doesn't incur more provider fees. If there's no match, or if the five-day retention period elapses, a subsequent call for the data is passed to the upstream provider. That call is treated as another first call, so the results are cached.

+If an ingestion job is for an identical geometry, referenced by the same resource ID, and with overlapping time to an already retrieved scene, Azure Data Manager for Agriculture uses the locally stored image. The image isn't downloaded again from the upstream provider. There's no expiration for this pixel-level caching.

+## Satellite sources that Azure Data Manager for Agriculture supports

+While Azure Data Manager for Agriculture is in preview, it supports ingesting data from the Sentinel-2 constellation.

+[Sentinel-2](https://sentinel.esa.int/web/sentinel/missions/sentinel-2) is a satellite constellation that the European Space Agency (ESA) launched under the Copernicus mission. This constellation has a pair of satellites and carries a multispectral instrument (MSI) payload that samples 13 spectral bands: four bands at 10 m, six bands at 20 m, and three bands at 60-m spatial resolution.

+Sentinel-2 has two products:

+* Level 1 data for the top of the atmosphere.

+* Level 2 data for the bottom of the atmosphere. This variant is atmospherically corrected.

+Azure Data Manager for Agriculture supports ingesting and retrieving Sentinel_2_L2A and Sentinel_2_L1C data from Sentinel 2.

+APIs that you use to ingest and read satellite data (for Sentinel-2) in Azure Data Manager for Agriculture support the following image names and resolutions:

+| Category | Image name | Description | Native resolution |

+|Raw bands| B01 | Coastal aerosol | 60 m |

+|Raw bands| B02 | Blue| 10 m |

+|Raw bands| B03 | Green | 10 m |

+|Raw bands| B04 | Red | 10 m |

+|Raw bands| B05 | Vegetation red edge | 20 m |

+|Raw bands| B06 | Vegetation red edge | 20 m |

+|Raw bands| B07 | Vegetation red edge | 20 m |

+|Raw bands| B08 | Near infrared (NIR) | 10 m |

+|Raw bands| B8A | Narrow NIR | 20 m |

+|Raw bands| B09 | Water vapor | 60 m |

+|Raw bands| B11 | Short-wave infrared (SWIR) | 20 m |

+|Raw bands| B12 | SWIR | 20 m |

+|Sen2Cor processor output| AOT | Aerosol optical thickness map | 10 m |

+|Sen2Cor processor output| SCL | Scene classification data | 20 m |

+|Sen2Cor processor output| SNW | Snow probability| 20 m |

+|Sen2Cor processor output| CLD | Cloud probability| 20 m |

+|Derived indices| NDVI | Normalized difference vegetation index | 10 m/20 m/60 m (user defined) |

+|Derived indices| NDWI | Normalized difference water index | 10 m/20 m/60 m (user defined) |

+|Derived indices| EVI | Enhanced vegetation index | 10 m/20 m/60 m (user defined) |

+|Derived indices| LAI | Leaf area index | 10 m/20 m/60 m (user defined) |

+|Derived indices| LAIMask | Leaf area index mask | 10 m/20 m/60 m (user defined) |

+|CLP| Cloud probability based on [s2cloudless](https://github.com/sentinel-hub/sentinel2-cloud-detector) | Values range from `0` (no clouds) to `255` (clouds). | 10 m/20 m/60 m (user defined)|

+|CLM| Cloud masks based on [s2cloudless](https://github.com/sentinel-hub/sentinel2-cloud-detector) | Value of `1` represents clouds, `0` represents no clouds, and `255` represents no data. | 10 m/20 m/60 m (user defined)|

+|dataMask | Binary mask to denote availability of data | Value of `0` represents unavailability of data or pixels lying outside the area of interest. | Not applicable, per pixel value|

+Azure Data Manager for Agriculture uses CRS EPSG: 4326 for Sentinel-2 data. The resolutions quoted in the APIs are at the equator.

+For the preview:

+* A maximum of five satellite jobs can run concurrently, per tenant.

+* A satellite job can ingest data for a maximum of one year in a single API call.

+* Only TIFs are supported.

+* Only 10-m, 20-m, and 60-m images are supported.

+* [Test the Azure Data Manager for Agriculture REST APIs](/rest/api/data-manager-for-agri)

+ Title: Ingest sensor data in Azure Data Manager for Agriculture

+description: Get step-by-step guidance for ingesting sensor data.

+# Ingest sensor data in Azure Data Manager for Agriculture

+Smart agriculture, also known as precision agriculture, allows growers to maximize yields by using minimal resources such as water, fertilizer, and seeds. By deploying sensors, growers and research organizations can begin to understand crops at a micro scale, conserve resources, reduce impact on the environment, and maximize crop yield. Sensors enable important ground-truth data (such as soil moisture, rainfall, and wind speed). This data, in turn, improves the accuracy of recommendations.

+* Location sensors, which determine latitude, longitude, and altitude

+* Electrochemical sensors, which determine pH and soil nutrients

+* Soil moisture sensors

+* Airflow sensors, which determine the pressure required to push a predetermined amount of air into the ground at a prescribed depth

+* Weather sensors

+There's a large ecosystem of sensor providers that help growers to monitor and optimize crop performance. Sensor-based data also enables an understanding of the changing environmental factors.

+Sensors are placed in a field based on its characteristics. Sensors record measurements and transfer the data to the connected node. Each node has one or more sensors connected to it. Nodes equipped with internet connectivity can push data directly to the cloud. Other nodes use an Internet of Things (IoT) agent to transfer data to the gateway.

+Gateways collect all essential data from the nodes and push it securely to the cloud via cellular connectivity, Wi-Fi, or Ethernet. After the data resides in a sensor partner's cloud, the sensor partner pushes the relevant sensor data to the dedicated Azure IoT Hub endpoint that Azure Data Manager for Agriculture provides.

+In addition to the preceding approach, IoT devices (sensors, nodes, and gateway) can push the data directly to the IoT Hub endpoint. In both cases, the data first reaches IoT Hub, where the next set of processing happens.

+The following diagram depicts the topology of a sensor in Azure Data Manager for Agriculture. Each geometry under a party has a set of devices placed within it. A device can be either a node or a gateway, and each device has a set of sensors associated with it. Sensors send the recordings via gateway to the cloud. Sensors are tagged with GPS coordinates to help in creating a geospatial time series for all measured data.

+* Learn how to [get started with pushing and consuming sensor data](./how-to-set-up-sensor-as-customer-and-partner.md).

+* Learn how to [get started as a customer](./how-to-set-up-sensors-customer.md) to consume sensor data from a supported sensor partner like Davis Instruments.

+* Learn how to [get started as a sensor partner](./how-to-set-up-sensors-partner.md) to push sensor data into Azure Data Manager for Agriculture.

+ Title: Ingest weather forecast data in Azure Data Manager for Agriculture

+description: Learn how to fetch weather data from various weather data providers through extensions and provider-agnostic APIs.

+# Ingest weather forecast data in Azure Data Manager for Agriculture

+Weather is a highly democratized service in the agriculture industry. Azure Data Manager for Agriculture offers customers the ability to work with the weather provider of their choice.

+Azure Data Manager for Agriculture provides current and forecast weather data through an extension-based and provider-agnostic approach. You can work with a provider of your choice by following the [steps for writing a weather extension](./how-to-write-weather-extension.md).

+Because Azure Data Manager for Agriculture provides weather data through a provider-agnostic approach, you don't have to be familiar with a provider's APIs. Instead, you can use the same Azure Data Manager for Agriculture APIs irrespective of the provider.

+Here are some notes about the behavior of provider-agnostic APIs:

+* You can request weather data for up to 50 locations in a single call.

+* Forecast data isn't older than 15 minutes. Data for current conditions isn't older than 10 minutes.

+* After the initial call is made for a location, the data is cached for the defined time to live (TTL).

+* To keep the cache warm, you can use the `apiFreshnessTimeInMinutes` parameter in the weather extension. The platform keeps a job running for the defined amount of time and updates the cache. The default value is zero, which means the cache isn't kept warm by default.

+The following sections provide the commands to fetch weather data and ingest it into Azure Data Manager for Agriculture.

+## Step 1: Install the weather extension

+To install the extension, run the following command by using the Azure Resource Manager ARMClient tool.

+Replace all values within angle brackets (`<>`) with your respective environment values. The extension ID that's currently supported is `IBM.TWC`.

+Here's sample output for the installation command:

+After you finish installing the extension, you can ingest weather data.

+If you want to update `apiFreshnessTimeInMinutes`, update the extension by using the following PowerShell command. Replace all values within angle brackets with your respective environment values.

+The preceding update command merges patch operations. It updates freshness time for only the API mentioned in the command and retains the freshness time values for other APIs as they were before.

+Here's sample output for the update command:

+After you get the credentials that are required to access the APIs, you need to call the [Weather Data API](/rest/api/data-manager-for-agri/dataplane-version2022-11-01-preview/weather-data) to fetch weather data.

+description: Learn about solutions that ISVs build on top of Azure Data Manager for Agriculture.

+# ISV solution framework in Azure Data Manager for Agriculture

+In this article, you learn how Azure Data Manager for Agriculture provides a framework for customers to use solutions built by Bayer and other independent software vendor (ISV) partners.

+The agriculture industry is going through a significant technology transformation. Technology is playing a key role in building sustainable agriculture.

+The adoption of technology like drones, satellite imagery, and Internet of Things (IoT) devices has increased. These source systems generate large volumes of data that's stored in the cloud. Companies want to efficiently manage this data and derive actionable insights that they can use to achieve more with less.

+Azure Data Manager for Agriculture provides a core technology platform that hides all the technical complexity and helps customers focus on building their core business logic and drive business value.

+The solution framework is built on top of Azure Data Manager for Agriculture to provide extensibility.

+The solution framework:

+* Enables ISV partners to apply their deep domain knowledge and build industry-specific solutions on top of Azure Data Manager for Agriculture.

+* Helps ISV partners generate revenue by monetizing their solutions and publishing them on Azure Marketplace.

+* Provides a simplified onboarding experience for ISV partners and customers.

+* Offers integration that's based on asynchronous APIs.

+* Complies with data privacy standards to help ensure that ISV partners and customers have the right level of access.

+Here are a few examples of how an ISV partner could use the solution framework to build an industry-specific solution:

+* **Yield prediction model**: Build a yield model by using historical data for a specific geometry, forecast estimated crop yield for the upcoming season, and track progress.

+* **Carbon emission model**: Estimate the amount of carbon emitted from a field based on imagery and sensor data for a particular farm.

+* **Crop identification**: Use imagery data to identify crops growing in an area of interest.

+An ISV partner can come up with its own specific scenario and build a solution.

+Bayer built the following solutions in partnership with Microsoft. A customer can install them on top of an Azure Data Manager for Agriculture instance.

+To install the preceding solutions, see the [article about working with ISV solutions](./how-to-set-up-isv-solution.md).

+* [Test the Azure Data Manager for Agriculture REST APIs](/rest/api/data-manager-for-agri)

+ Title: Generative AI in Azure Data Manager for Agriculture

+description: Learn how to use generative AI features in Azure Data Manager for Agriculture.

+# Generative AI in Azure Data Manager for Agriculture

+The copilot templates for agriculture enable seamless retrieval of data stored in Azure Data Manager for Agriculture so that farming-related context and insights can be queried in a conversational context. These capabilities enable customers and partners to build their own agriculture copilots.

+Customers and partners can deliver insights to users around disease, yield, harvest windows, and more, by using actual planning and observational data. Although Azure Data Manager for Agriculture isn't required to operationalize copilot templates for agriculture, it enables customers to more easily integrate generative AI scenarios for their users.

+Many customers have proprietary data outside Azure Data Manager for Agriculture; for example, agronomy PDFs or market price data. These customers can benefit from an orchestration framework that allows for plugins, embedded data structures, and subprocesses to be selected as part of the query flow.

+Customers who have farm operations data in Azure Data Manager for Agriculture can use plugins that enable seamless selection of APIs mapped to farm operations. These plugins allow for a combination of results, calculation of area, ranking, and summarizing to help serve customer prompts.

+The copilot templates for agriculture make generative AI in agriculture a reality.

+> Azure might include preview, beta, or other prerelease features, services, software, or regions offered by Microsoft for optional evaluation. Previews are licensed to you as part of [your agreement](https://azure.microsoft.com/support) governing the use of Azure, and are subject to terms applicable to previews.

+> The preview of Azure Data Manager for Agriculture and related Microsoft generative AI services are subject to [additional terms](https://azure.microsoft.com/support/legal/preview-supplemental-terms/). These additional terms supplement your agreement governing your use of Azure. If you don't agree to these terms, don't use the previews.

+- An instance of [Azure OpenAI Service](../ai-services/openai/how-to/create-resource.md) created in your Azure subscription

+- [Azure Key Vault](../key-vault/general/quick-create-portal.md)

+- [Azure Container Registry](../container-registry/container-registry-get-started-portal.md)

+## High-level architecture

+You have full control because deployment of key components is within your tenant. The copilot templates for agriculture are available via a Docker container, which is deployed to your Azure App Service instance.

+We recommend that you apply content and safety filters on your Azure OpenAI instance. Taking this step helps ensure that the generative AI capability is aligned with guidelines from Microsoft's Office of Responsible AI. To get started, follow the [instructions on how to use content filters with Azure OpenAI](../ai-services/openai/how-to/content-filters.md).

+## Use cases for farm operations

+Azure Data Manager for Agriculture supports seamless selection of APIs mapped to farm operations. This support enables use cases that are based on tillage, planting, applications, and harvesting types of farm operations. Here's a sample list of queries that you can test and use:

+- Show me active fields

+- What crop was planted in my field (use field name)

+- Tell me the application details for my field (use field name)

+- Give me a list of all fields with planting dates

+- Give me a list of all fields with application dates

+- What is the delta between planted and harvested fields

+- Which farms were harvested

+- What is the area of harvested fields

+- Convert area to acres/hectares

+- What is the average yield for my field (use field name) with crop (use crop name)

+- What is the effect of planting dates on yield for crop (use crop name)

+These use cases can help input providers to plan equipment, seeds, applications, and related services and engage better with the farmer.

+- Fill in [this onboarding form](https://forms.office.com/r/W4X381q2rd) to get started with testing the copilot templates feature.

+- Test the [Azure Data Manager for Agriculture REST APIs](/rest/api/data-manager-for-agri).

+ Title: API throttling guidance for Azure Data Manager for Agriculture

+description: This article provides information on API throttling limits to plan usage in Azure Data Manager for Agriculture.

+# API throttling guidance for Azure Data Manager for Agriculture

+Throttling limits the number of requests to a service in a time span to prevent the overuse of resources. The throttling of the REST API in Azure Data Manager for Agriculture allows more consistent performance within a time span for customers who call the service's APIs.

+Azure Data Manager for Agriculture can handle a high volume of requests. If an overwhelming number of requests occur from a few customers, throttling helps maintain optimal performance and reliability for all customers.

+Throttling limits are contingent on the selected version and the capabilities of the product that a customer is using. Azure Data Manager for Agriculture supports two distinct versions:

+- **Standard**: The version that we generally recommend.

+- **Basic**: Suitable for prototyping requirements.

+These limits operate within three time windows (per one minute, per five minutes, and per one month) to safeguard against sudden surges in traffic.

+This article shows you how to track the number of requests that remain before you reach the limit, and how to respond when you reach the limit. Throttling limits apply to [these APIs](/rest/api/data-manager-for-agri/#data-plane-rest-apis).

+## Classification of APIs

+Azure Data Manager for Agriculture APIs fall into three main categories:

+- **Write operations**: APIs that use REST API methods like `PATCH`, `POST`, and `DELETE` for altering data.

+- **Read operations**: APIs that use the REST API method type `GET` to retrieve data, including search APIs of the method type `POST`.

+- **Long-running job operations**: Long-running asynchronous job APIs that use the REST API method type `PUT`.

+The overall available quota units, as explained in the following table, are shared among these categories. For instance, using the entire quota on write operations means no remaining quota for other operations. Each operation consumes a specific unit of quota, which helps you track the remaining quota for further use.

+Operation | Unit cost for each request|

+Long-running job: [solution inference](/rest/api/data-manager-for-agri/#solution-inferences) | 5 |

+Long-running job: [farm operation](/rest/api/data-manager-for-agri/#farm-operations) | 5 |

+Long-running job: image rasterization | 2 |

+Long-running job: cascading deletion of an entity | 2 |

+Long-running job: [weather ingestion](/rest/api/data-manager-for-agri/#weather) | 1 |

+Long-running job: [satellite ingestion](/rest/api/data-manager-for-agri/#satellite) | 1 |

+¹An extra unit cost is taken into account for each item returned in the response when you're retrieving more than one item.

+## API limits for the Basic version

+The following table lists the total available units per category for the Basic version:

+Operation | Throttling time window | Units reset after each time window|

+Write/read| Per one minute | 25,000 |

+Write/read| Per five minutes| 100,000|

+Write/read| Per one month| 5,000,000 |

+Long-running job| Per five minutes| 1000|

+Long-running job| Per one month| 100,000 |

+## API limits for the Standard version

+The Standard version offers a fivefold increase in API quota per month, compared to the Basic version. All other quota limits remain unchanged.

+The following table lists the total available units per category for the Standard version:

+Operation | Throttling time window | Units reset after each time window|

+Write/read| Per one minute | 25,000 |

+Write/read| Per five minutes| 100,000|

+Write/read| Per one month| 25,000,000 ¹ |

+Long-running job| Per five minutes| 1000|

+Long-running job| Per one month| 500,000 ¹|

+¹This limit is five times the Basic version's limit.

+When you reach the limit, you receive the HTTP status code **429 Too many requests**. The response includes a **Retry-After** value, which specifies the number of seconds your application should wait (or sleep) before it sends the next request.

+If you send a request before the retry value elapses, your request isn't processed and a new retry value is returned. After the specified time elapses, you can make requests again to Azure Data Manager for Agriculture. Trying to establish a TCP connection or using different user authentication methods doesn't bypass these limits, because they're specific to each tenant.

+## Frequently asked questions

+### If I exhaust the allocated API quota entirely for write operations within a per-minute time window, can I successfully make requests for read operations within the same time window?

+The quota limits are shared among the listed operation categories. Using the entire quota for write operations implies no remaining quota for other operations. This article details the specific quota units consumed for each operation.

+### How can I calculate the total number of successful requests allowed for a particular time window?

+The total allowed number of successful API requests depends on the version that you provisioned and the time window in which you make requests.

+For instance, with the Standard version, you can make 25,000 (units reset after each time window) / 5 (unit cost for each request) = 5,000 write operation APIs within a one-minute time window. Or you can use a combination of 4,000 write operations and 5,000 read operations, which results in 4,000 * 5 + 5,000 * 1 = 25,000 total units of consumption.

+Similarly, for the Basic version, you can perform 5,000,000 (units reset after each time window) / 1 (unit cost for each request) = 5,000,000 read operation APIs within a one-month time window.

+### How many sensor events can a customer ingest as the maximum number?

+The system allows a maximum of 100,000 event ingestions per hour. Although new events are continually accepted, there might be a delay in processing. The delay might mean that these events aren't immediately available for real-time egress scenarios alongside the ingestion.

+- [Learn about the hierarchy model and how to create and organize your agriculture data](./concepts-hierarchy-model.md)

+- [Test the Azure Data Manager for Agriculture REST APIs](/rest/api/data-manager-for-agri)

+- [Learn about common API response headers](/rest/api/data-manager-for-agri/common-rest-response-headers)

+ Title: Release notes for Microsoft Azure Data Manager for Agriculture Preview

+# Release notes for Azure Data Manager for Agriculture Preview

+Azure Data Manager for Agriculture Preview is updated on an ongoing basis. To keep you informed about recent developments, this article provides information about:

+### Copilot templates for agriculture

+Copilot templates for agriculture enable seamless retrieval of data stored in Azure Data Manager for Agriculture and customers' own data. Many customers have proprietary data outside Azure Data Manager for Agriculture; for example, agronomy PDFs or market price data. Such customers can benefit from an orchestration framework that allows for plugins, embedded data structures, and subprocesses to be selected as part of the query flow.

+Although Azure Data Manager for Agriculture isn't required to operationalize copilot templates for agriculture, it enables customers to more easily integrate generative AI scenarios for their users. Learn more in [Generative AI in Azure Data Manager for Agriculture](concepts-llm-apis.md).

+### Generative AI capability

+The generative AI capability in Azure Data Manager for Agriculture enables seamless selection of APIs mapped to farm operations. This support enables use cases that are based on tillage, planting, applications, and harvesting types of farm operations.

+Plugins in the generative AI capability allow for a combination of results, calculation of area, ranking, and summarizing to help serve customer prompts. These capabilities enable customers and partners to build their own agriculture copilots that deliver insights to farmers. Learn more in [Generative AI in Azure Data Manager for Agriculture](concepts-llm-apis.md).

+We improved the satellite ingestion capability. The improvements include:

+- Improvements to the reprojection method to more accurately reflect on-the-ground dimensions across the globe.

+- Nomenclature adaptations to better converge with standards.

+These improvements might require changes in how you consume services to ensure continuity. You can find more details on the satellite service and these changes in [Ingest satellite imagery in Azure Data Manager for Agriculture](concepts-ingest-satellite-imagery.md).

+Listing of activities by party ID and by activity ID is consolidated into a more powerful, common search endpoint. Read more in [Work with farm activities and activity data in Azure Data Manager for Agriculture](how-to-ingest-and-egress-farm-operations-data.md).

+### Enhancement of the Azure portal experience

+We released a new user-friendly experience to install independent software vendor (ISV) solutions that are available for Azure Data Manager for Agriculture. You can now go to your Azure Data Manager for Agriculture instance on the Azure portal, view available solutions, and install them in a seamless experience.

+Currently, the available ISV solutions are from Bayer AgPowered Services. You can view the listing in [Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps?search=bayer&page=1). You can learn more about installing ISV solutions in [Work with an ISV solution](how-to-set-up-isv-solution.md).

+### Weather API update

+We deprecated the old weather APIs from API version 2023-07-01. We replaced them with simple yet powerful provider-agnostic weather APIs. See the [API documentation](/rest/api/data-manager-for-agri/#weather).

+We added support for Climate FieldView as a built-in data source. You can now automatically sync planting, application, and harvest activity files from FieldView accounts directly into Azure Data Manager for Agriculture. Learn more about this capability in [Work with farm activities data in Azure Data Manager for Agriculture](concepts-farm-operations-data.md).

+### Geospatial support in the data model

+We updated our data model to improve flexibility. The boundary object is deprecated in favor of a geometry property that's now supported in nearly all data objects. This change brings consistency to how space is handled across hierarchy, activity, and observation themes. It allows for more flexible integration when you're ingesting data from a provider that has strict hierarchy requirements.

+You can now sync data that might not perfectly align with an existing hierarchy definition and resolve the conflicts with spatial overlap queries. Learn more in [Hierarchy model in Azure Data Manager for Agriculture](concepts-hierarchy-model.md).

+Azure Data Manager for Agriculture supports a range of data ingress connectors. These connections require customer keys in a bring your own license (BYOL) model. You can use your license keys safely by storing your secrets in a key vault, enabling system identity, and providing read access to Azure Data Manager for Agriculture. Details are available in [Store and use your own license keys in Azure Data Manager for Agriculture](concepts-byol-and-credentials.md).

+You can start pushing data from your own sensors into Azure Data Manager for Agriculture. This capability useful if your sensor provider doesn't want to take steps to onboard its sensors or if you don't have such support from your sensor provider. Details are available in [Sensor integration as both partner and customer in Azure Data Manager for Agriculture](how-to-set-up-sensor-as-customer-and-partner.md).

+### API throttling

+Azure Data Manager for Agriculture implements API throttling to help ensure consistent performance by limiting the number of requests within a specified time frame. Throttling prevents resource overuse and maintains optimal performance and reliability for all customers. Details are available in [API throttling guidance for Azure Data Manager for Agriculture](concepts-understanding-throttling.md).

+In Azure Data Manager for Agriculture Preview, you can monitor how and when your resources are accessed, and by whom. You can also debug reasons for failure of data-plane requests. [Audit logs](how-to-set-up-audit-logs.md) are now available for your use.

+You can connect to Azure Data Manager for Agriculture Preview from your virtual network via a private endpoint. You can then limit access to your Azure Data Manager for Agriculture instance over these private IP addresses. [Private links](how-to-set-up-private-links.md) are now available for your use.

+To support scalable ingestion of geometry-clipped imagery, we partnered with Sentinel Hub by Sinergise to provide a seamless BYOL experience. Read more about the satellite connector in [Ingest satellite imagery in Azure Data Manager for Agriculture](concepts-ingest-satellite-imagery.md).

+### Key announcement: Preview release

+Azure Data Manager for Agriculture is now available in preview. See the [blog post](https://azure.microsoft.com/blog/announcing-microsoft-azure-data-manager-for-agriculture-accelerating-innovation-across-the-agriculture-value-chain/).

+- [Learn about the hierarchy model and how to create and organize your agriculture data](./concepts-hierarchy-model.md)

+- [Test the Azure Data Manager for Agriculture REST APIs](/rest/api/data-manager-for-agri)

+The following is a typical template structure:

+- *infra folder* - The infra folder is not used in `azd` with ADE. It contains all of the Bicep or Terraform infrastructure as code files for the azd template. ADE provides the infrastructure as code files for the `azd` template. You don't need to include these files in your `azd` template.

+- [Make your project compatible with Azure Developer CLI](/azure/developer/azure-developer-cli/make-azd-compatible?pivots=azd-create)

+In Azure Deployment Environments, you use [managed identities](../active-directory/managed-identities-azure-resources/overview.md) to provide elevation-of-privilege capabilities. Identities can help you provide self-serve capabilities to your development teams without giving them access to the target subscriptions in which the Azure resources are created.

+Catalogs help you provide a set of curated IaC templates for your development teams to create environments. Microsoft provides a [*quick start* catalog](https://github.com/microsoft/devcenter-catalog) that contains a set of sample environment definitions. You can attach the quick start catalog to a dev center to make these environment definitions available to all the projects associated with the dev center. You can modify the sample environment definitions to suit your needs.

+## Built-in roles

+Azure Deployment Environments supports three [built-in roles](../role-based-access-control/built-in-roles.md):

+- **Dev Center Project Admin**: Creates environments and manages the environment types for a project.

+- **Deployment Environments User**: Creates environments based on appropriate access.

+- **Deployment Environments Reader**: Reads environments that other users created.

+description: Enable developer teams to spin up infrastructure for deploying apps with templates, adding governance for Azure resource types, security, and cost.

+#customer intent: As a customer, I want to understand to purpose and capabilities of Azure Deployment Environments so that I can determine if the service will benefit my developers.

+A [*deployment environment*](./concept-environments-key-concepts.md#environments) is a collection of Azure infrastructure resources defined in a template called an [*environment definition*](./concept-environments-key-concepts.md#environment-definitions). Developers can deploy infrastructure defined in the templates in subscriptions where they have access, and build their applications on the infrastructure. For example, you can define a deployment environment that includes a web app, a database, and a storage account. Your web developer can begin coding the web app without worrying about the underlying infrastructure.

+Platform engineers can create and manage environment definitions. To specify which environment definitions are available to developers, platform engineers can associate environment definitions with projects, and assign permissions to developers. They can also apply Azure governance based on the type of environment, such as sandbox, testing, staging, or production.

+The following diagram shows an overview of Azure Deployment Environments capabilities. Platform engineers define infrastructure templates and configure subscriptions, identity, and permissions. Developers create environments based on the templates, and build and deploy applications on the infrastructure. Environments can support different scenarios, like on-demand environments, sandbox environments for testing, and CI/CD pipelines for continuous integration and continuous deployment.

+Azure Deployment Environments currently supports only Azure Resource Manager (ARM) templates.

+Common [scenarios](./concept-environments-scenarios.md) for Azure Deployment Environments include:

+Azure Deployment Environments helps platform engineers apply the right set of policies and settings on various types of environments, control the resource configuration that developers can create, and track environments across projects. They perform the following tasks:

+### Developer scenarios

+Developers can create environments whenever they need them, and develop their applications on the infrastructure. They can use Azure Deployment Environments to do the following tasks:

+- Deploy a preconfigured environment for any stage of the development cycle.

+- Spin up a sandbox environment to explore Azure.

+- Create and manage environments through the [developer portal](./quickstart-create-access-environments.md), with the [Azure CLI](./how-to-create-access-environments.md) or with the [Azure Developer CLI](./how-to-create-environment-with-azure-developer.md).

+Organize environment definitions by the type of application that development teams are working on, rather than using an unorganized list of templates or a traditional IaC setup.

+## Related content

+- [Quickstart: Create dev center and project (Azure Resource Manager)](./quickstart-create-dev-center-project-azure-resource-manager.md)

+Microsoft Intune is used to manage your dev boxes. Every Dev Box user needs one Microsoft Intune license and can create multiple dev boxes. After a dev box is provisioned, you can manage it like any other Windows device in Microsoft Intune. For example, you can create [device configuration profiles](/mem/intune/configuration/device-profiles) to turn different settings on and off in Windows, or push apps and updates to your usersΓÇÖ dev boxes.

+Azure Compute Gallery is a service for managing and sharing images. A gallery is a repository that's stored in your Azure subscription and helps you build structure and organization around your image resources. Dev Box supports GitHub, Azure Repos, and Bitbucket repositories to provide an image gallery.

+### Image version requirements

+ - Windows 10 Enterprise version 20H2 or later

+ - Windows 11 Enterprise 21H2 or later

+ - For more information about creating a generalized image, see [Reduce provisioning and startup times](#reduce-provisioning-and-startup-times) for more information.

+- Single-session VM image (Multiple-session VM images aren't supported.)

+ - For information about how to remove a recovery partition, see the [Windows Server command: delete partition](/windows-server/administration/windows-commands/delete-partition).

+ - The OS disk size is automatically adjusted to the size specified in the SKU description of the Windows 365 license.

+### Reduce provisioning and startup times

+When you create a generalized VM to capture to an image, the following issues can affect provisioning and startup times:

+1. Create the image by using these three sysprep options: `/generalize /oobe /mode:vm`.

+ - These options prevent a lengthy search for and installation of drivers during the first boot. For more information, see [Sysprep Command-Line Options](/windows-hardware/manufacture/desktop/sysprep-command-line-options?view=windows-11#modevm&preserve-view=true).1. Enable the Read/Write cache on the OS disk.

+ - To verify the cache is enabled, open the Azure portal and navigate to the image. Select **JSON view**, and make sure `properties.storageProfile.osDisk.caching` value is `ReadWrite`.

+1. Enable nested virtualization in your base image:

+ - In the UI, open **Turn Windows features on or off** and select **Virtual Machine Platform**.

+ - Or run the following PowerShell command: `Enable-WindowsOptionalFeature -FeatureName VirtualMachinePlatform -Online`

+

+1. Disable the reserved storage state feature in the image by using the following command: `DISM.exe /Online /Set-ReservedStorageState /State:Disabled`.

+ - For more information, see [DISM Storage reserve command-line options](/windows-hardware/manufacture/desktop/dism-storage-reserve?view=windows-11#set-reservedstoragestate&preserve-view=true).

+

+1. Run `defrag` and `chkdsk` during image creation, then disable the `chkdisk` and `defrag` scheduled tasks.

+You can enable or disable rate limiting for ExpressRoute Direct circuits at the circuit level. For more information, see [Rate limiting for ExpressRoute Direct circuits](rate-limit.md).

+- Learn how to [Enable Rate limiting for ExpressRoute Direct circuits](rate-limit.md).

+ CREATE TABLE flightsintervaldata1 (arrivalAirportCandidatesCount INT, estArrivalHour INT) PARTITIONED BY (estArrivalHour) WITH ('connector' = 'delta', 'table-path' = 'abfs://container@storage_account.dfs.core.windows.net/delta-output');

+ 'password' = 'password',

+Move the jar flink-table-planner_2.12-1.17.0-*.*.*.*.jar located in webssh pod's /opt to /lib and move out the jar flink-table-planner-loader1.17.0-*.*.*.*.jar /opt/flink-webssh/opt/ from /lib. Refer to [issue](https://issues.apache.org/jira/browse/FLINK-25128) for more details. Perform the following steps to move the planner jar.

+mv /opt/flink-webssh/lib/flink-table-planner-loader-1.17.0-*.*.*.*.jar /opt/flink-webssh/opt/

+mv /opt/flink-webssh/opt/flink-table-planner_2.12-1.17.0-*.*.*.*.jar /opt/flink-webssh/lib/

+Move the jar `flink-table-planner-loader-1.17.0-*.*.*.jar` located in webssh pod's `/opt to /lib` and move out the jar `flink-table-planner-loader-1.17.0-*.*.*.jar` from `lib`. Refer to issue for more details. Perform the following steps to move the planner jar.

+ :::image type="content" source="./media/in-place-upgrade/upgrade-cluster.png" alt-text="Screenshot showing the type of the upgrade as cluster upgrade." border="true" lightbox="./media/in-place-upgrade/upgrade-cluster.png"

+|Name<br />_{(Azure portal)} |Description |Effect(s) |Version<br />_(GitHub) |

+|||||

+|[Azure API for FHIR should use a customer-managed key to encrypt data at rest](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F051cba44-2429-45b9-9649-46cec11c7119) |Use a customer-managed key to control the encryption at rest of the data stored in Azure API for FHIR when this is a regulatory or compliance requirement. Customer-managed keys also deliver double encryption by adding a second layer of encryption on top of the default one done with service-managed keys. |audit, Audit, disabled, Disabled |[1.1.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/API%20for%20FHIR/HealthcareAPIs_EnableByok_Audit.json) |

+|[Azure API for FHIR should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1ee56206-5dd1-42ab-b02d-8aae8b1634ce) |Azure API for FHIR should have at least one approved private endpoint connection. Clients in a virtual network can securely access resources that have private endpoint connections through private links. For more information, visit: [https://aka.ms/fhir-privatelink](https://aka.ms/fhir-privatelink). |Audit, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/API%20for%20FHIR/HealthcareAPIs_PrivateLink_Audit.json) |

+|[CORS should not allow every domain to access your API for FHIR](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0fea8f8a-4169-495d-8307-30ec335f387d) |Cross-Origin Resource Sharing (CORS) should not allow all domains to access your API for FHIR. To protect your API for FHIR, remove access for all domains and explicitly define the domains allowed to connect. |audit, Audit, disabled, Disabled |[1.1.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/API%20for%20FHIR/HealthcareAPIs_RestrictCORSAccess_Audit.json) |

+FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

+ Title: Built-in policy definitions for Azure Health Data Services

+description: Lists Azure Policy built-in policy definitions for Azure Health Data Services. These built-in policy definitions provide common approaches to managing your Azure resources.

+# Azure Policy built-in definitions for Azure Health Data Services

+This page is an index of [Azure Policy](./../../articles/governance/policy/overview.md) built-in policy

+definitions for Azure Health Data Services. For additional Azure Policy built-ins for other services, see

+[Azure Policy built-in definitions](./../../articles/governance/policy/samples/built-in-policies.md).

+The name of each built-in policy definition links to the policy definition in the Azure portal. Use

+the link in the **Version** column to view the source on the

+[Azure Policy GitHub repo](https://github.com/Azure/azure-policy).

+|Name<br />_{(Azure portal)} |Description |Effect(s) |Version<br />_(GitHub) |

+|||||

+|[Azure Health Data Services workspace should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F64528841-2f92-43f6-a137-d52e5c3dbeac) |Health Data Services workspace should have at least one approved private endpoint connection. Clients in a virtual network can securely access resources that have private endpoint connections through private links. For more information, visit: [https://aka.ms/healthcareapisprivatelink](https://aka.ms/healthcareapisprivatelink). |Audit, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Health%20Data%20Services%20workspace/PrivateLink_Audit.json) |

+|[CORS should not allow every domain to access your FHIR Service](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffe1c9040-c46a-4e81-9aea-c7850fbb3aa6) |Cross-Origin Resource Sharing (CORS) should not allow all domains to access your FHIR Service. To protect your FHIR Service, remove access for all domains and explicitly define the domains allowed to connect. |audit, Audit, disabled, Disabled |[1.1.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Healthcare%20APIs/FHIR_Service_RestrictCORSAccess_Audit.json) |

+|[DICOM Service should use a customer-managed key to encrypt data at rest](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F14961b63-a1eb-4378-8725-7e84ca8db0e6) |Use a customer-managed key to control the encryption at rest of the data stored in Azure Health Data Services DICOM Service when this is a regulatory or compliance requirement. Customer-managed keys also deliver double encryption by adding a second layer of encryption on top of the default one done with service-managed keys. |Audit, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Healthcare%20APIs/DICOM_Service_CMK_Enabled.json) |

+|[FHIR Service should use a customer-managed key to encrypt data at rest](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc42dee8c-0202-4a12-bd8e-3e171cbf64dd) |Use a customer-managed key to control the encryption at rest of the data stored in Azure Health Data Services FHIR Service when this is a regulatory or compliance requirement. Customer-managed keys also deliver double encryption by adding a second layer of encryption on top of the default one done with service-managed keys. |Audit, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Healthcare%20APIs/FHIR_Service_CMK_Enabled.json) |

+## Next steps

+- See the built-ins on the [Azure Policy GitHub repo](https://github.com/Azure/azure-policy).

+- Review the [Azure Policy definition structure](./../../articles/governance/policy/concepts/definition-structure.md).

+- Review [Understanding policy effects](./../../articles/governance/policy/concepts/effects.md).

+FHIR&#174; is a registered trademark of [HL7](https://hl7.org/fhir/) and is used with the permission of HL7.

+ Title: Enable data partitioning for the DICOM service in Azure Health Data Services

+description: Learn how to enable data partitioning for efficient storage and management of medical images for the DICOM service in Azure Health Data Services.

+# Enable data partitioning

+Data partitioning allows you to set up a lightweight data partition scheme to store multiple copies of the same image with the same unique identifier (UID) in a single DICOM instance.

+Although UIDs should be [unique across all contexts](http://dicom.nema.org/dicom/2013/output/chtml/part05/chapter_9.html), it's common practice for healthcare providers to write DICOM files to portable storage media and then give them to a patient. The patient then gives the files to another healthcare provider, who then transfers the files into a new DICOM storage system. Therefore, multiple copies of one DICOM file do commonly exist in isolated DICOM systems. Data partitioning provides an on-ramp for your existing data stores and workflows.

+## Limitations

+- The partitions feature can't be turned off after you turn it on.

+- Querying across partitions isn't supported.

+- Updating and deleting partitions is also not supported.

+## Enable data partitions during initial deployment

+1. Select **Enable data partitions** when you deploy a new DICOM service. After data partitioning is turned on, it can't be turned off. In addition, data partitions can't be turned on for any DICOM service that is already deployed.

+ After the data partitions setting is turned on, the capability modifies the API surface of the DICOM server and makes any previous data accessible under the `Microsoft.Default` partition.

+ :::image type="content" source="media/enable-data-partitions/enable-data-partitions.png" alt-text="Screenshot showing the Enable data partitions option on the Create DICOM service page." lightbox="media/enable-data-partitions/enable-data-partitions.png":::

+> [!IMPORTANT]

+> Data partitions can't be disabled if partitions other than `Microsoft.Default` are present. When this situation happens, the system throws a `DataPartitionsFeatureCannotBeDisabledException` error on startup.

+## API changes

+### List all data partitions

+This command Lists all data partitions:

+```http

+GET /partitions

+```

+### Request header

+| Name | Required | Type | Description |

+| | | | - |

+| Content-Type | false | string | `application/json` is supported |

+### Responses

+| Name | Type | Description |

+| -- | -- | - |

+| 200 (OK) | `[Partition] []` | A list of partitions is returned. |

+| 204 (No Content) | | No partitions exist. |

+| 400 (Bad Request) | | Data partitions capability is disabled. |

+### STOW, WADO, QIDO, delete, export, update, and worklist APIs

+After partitions are enabled, STOW, WADO, QIDO, delete, export, update, and worklist requests must include a data partition URI segment after the base URI, with the form `/partitions/{partitionName}`, where `partitionName` is:

+ - Up to 64 characters long.

+ - Any combination of alphanumeric characters, `.`, `-`, and `_`, to allow both DICOM UID and GUID formats, as well as human-readable identifiers.

+| Action | Example URI |

+| - | - |

+| STOW | `POST /partitions/myPartition-1/studies` |

+| WADO | `GET /partitions/myPartition-1/studies/2.25.0000` |

+| QIDO | `GET /partitions/myPartition1/studies?StudyInstanceUID=2.25.0000` |

+| Delete | `DELETE /partitions/myPartition1/studies/2.25.0000` |

+| Export | `POST /partitions/myPartition1/export` |

+| Update | `POST /partitions/myPartition-1/studies/$bulkUpdate` |

+### New responses

+| Name | Message |

+| -- | |

+| 400 (Bad Request) | Data partitions capability is disabled. |

+| 400 (Bad Request) | `PartitionName` value is missing in the route segment. |

+| 400 (Bad Request) | Specified `PartitionName {PartitionName}` doesn't exist. |

+### Other APIs

+All other APIs, including extended query tags, operations, and change feed continue to be accessed at the base URI.

+### Manage data partitions

+The only management operation supported for partitions is an implicit creation during STOW and workitem create requests. If the partition specified in the URI doesn't exist, the system creates it implicitly and the response returns a retrieve URI including the partition path.

+### Partition definitions

+A partition is a unit of logical isolation and data uniqueness.

+| Name | Type | Description |

+| - | | -- |

+| PartitionKey | int | System-assigned identifier. |

+| PartitionName | string | Client-assigned unique name, up to 64 alphanumeric characters, `.`, `-`, or `_`. |

+| CreatedDate | string | The date and time when the partition was created. |

+| Parameter name | Description | Cardinality | Accepted values |

+| `inputFormat`| String that represents the name of the data source format. Only FHIR NDJSON files are supported. | 1..1 | `application/fhir+ndjson` |

+| `mode`| Import mode value. | 1..1 | For an initial-mode import, use the `InitialLoad` mode value. For incremental-mode import, use the `IncrementalLoad` mode value. If you don't provide a mode value, the `IncrementalLoad` mode value is used by default. |

+| `input`| Details of the input files. | 1..* | A JSON array with the three parts described in the following table. |

+| `type`| Resource type of the input file. | 0..1 | A valid [FHIR resource type](https://www.hl7.org/fhir/resourcelist.html) that matches the input file. |

+|`url`| Azure storage URL of the input file. | 1..1 | URL value of the input file. The value can't be modified. |

+| `etag`| ETag of the input file in the Azure storage. It's used to verify that the file content isn't changed after `import` registration. | 0..1 | ETag value of the input file.|

+ Title: Tutorial - Assign devices to multiple hubs using DPS

+Custom allocation policies give you more control over how devices are assigned to your IoT hubs. With custom allocation policies, you can define your own allocation policies when the policies provided by the Azure IoT Hub Device Provisioning Service (DPS) don't meet the requirements of your scenario. A custom allocation policy is implemented in a webhook hosted in [Azure Functions](../azure-functions/functions-overview.md) and configured on one or more individual enrollments and/or enrollment groups. When a device registers with DPS using a configured enrollment entry, DPS calls the webhook to find out which IoT hub the device should be registered to and, optionally, its initial state. To learn more, see [Understand custom allocation policies](concepts-custom-allocation.md).

+Devices are simulated using a provisioning sample included in the [Azure IoT C SDK](https://github.com/Azure/azure-iot-sdk-c).

+> * Use the Azure CLI to create a DPS instance and to create and link two Contoso division IoT hubs (**Contoso Toasters Division** and **Contoso Heat Pumps Division**) to it.

+> * Create an Azure Function that implements the custom allocation policy.

+> * Create a new enrollment group uses the Azure Function for the custom allocation policy.

+> * Create device symmetric keys for two simulated devices.

+> * Set up the development environment for the Azure IoT C SDK.

+> * Simulate the devices and verify that they are provisioned according to the example code in the custom allocation policy.

+- Git installed. For more information, see [Git downloads](https://git-scm.com/download/).

+- Azure CLI installed. For more information, see [How to install the Azure CLI](/cli/azure/install-azure-cli). Or, you can run the commands in this tutorial in the Bash environment in [Azure Cloud Shell](/azure/cloud-shell/overview).

+## Create the provisioning service and two IoT hubs

+1. First, set environment variables in your workspace to simplify the commands in this tutorial.

+ The DPS and IoT Hub names must be globally unique. Replace the `SUFFIX` placeholder with your own value.

+ Also, the Azure Function code you create later in this tutorial looks for IoT hubs that have either `-toasters-` or `-heatpumps-` in their names. If you change the suggested values, make sure to use names that contain the required substrings.

+ ```bash

+ #!/bin/bash

+ export RESOURCE_GROUP="contoso-us-resource-group"

+ export LOCATION="westus"

+ export DPS="contoso-provisioning-service-SUFFIX"

+ export TOASTER_HUB="contoso-toasters-hub-SUFFIX"

+ export HEATPUMP_HUB="contoso-heatpumps-hub-SUFFIX"

+ ```

+ ```powershell

+ # PowerShell

+ $env:RESOURCE_GROUP = "contoso-us-resource-group"

+ $env:LOCATION = "westus"

+ $env:DPS = "contoso-provisioning-service-SUFFIX"

+ $env:TOASTER_HUB = "contoso-toasters-hub-SUFFIX"

+ $env:HEATPUMP_HUB = "contoso-heatpumps-hub-SUFFIX"

+ ```

+ > [!TIP]

+ > The commands used in this tutorial create resources in the West US location by default. We recommend that you create your resources in the region nearest you that supports Device Provisioning Service. You can view a list of available locations by going to the [Azure Status](https://azure.microsoft.com/status/) page and searching for "Device Provisioning Service". In commands, locations can be specified either in one word or multi-word format; for example: westus, West US, WEST US, etc. The value is not case sensitive.

+1. Use the [az group create](/cli/azure/group#az-group-create) command to create an Azure resource group. An Azure resource group is a logical container into which Azure resources are deployed and managed.

+ The following example creates a resource group. We recommend that you use a single group for all resources created in this tutorial. This approach will make clean up easier after you're finished.

+ ```azurecli-interactive

+ az group create --name $RESOURCE_GROUP --location $LOCATION

+ ```

+1. Use the [az iot dps create](/cli/azure/iot/dps#az-iot-dps-create) command to create an instance of the Device Provisioning Service (DPS). The provisioning service is added to *contoso-us-resource-group*.

+ az iot dps create --name $DPS --resource-group $RESOURCE_GROUP --location $LOCATION

+ This command might take a few minutes to complete.

+1. Use the [az iot hub create](/cli/azure/iot/hub#az-iot-hub-create) command to create the **Contoso Toasters Division** IoT hub. The IoT hub is added to *contoso-us-resource-group*.

+ az iot hub create --name $TOASTER_HUB --resource-group $RESOURCE_GROUP --location $LOCATION --sku S1

+ This command might take a few minutes to complete.

+1. Use the [az iot hub create](/cli/azure/iot/hub#az-iot-hub-create) command to create the **Contoso Heat Pumps Division** IoT hub. This IoT hub also is added to *contoso-us-resource-group*.

+ ```azurecli-interactive

+ az iot hub create --name $HEATPUMP_HUB --resource-group $RESOURCE_GROUP --location $LOCATION --sku S1

+ This command might take a few minutes to complete.

+1. Run the following two commands to get the connection strings for the hubs you created.

+ ```azurecli-interactive

+ az iot hub connection-string show --hub-name $TOASTER_HUB --key primary --query connectionString -o tsv

+ az iot hub connection-string show --hub-name $HEATPUMP_HUB --key primary --query connectionString -o tsv

+ ```

+1. Run the following commands to link the hubs to the DPS resource. Replace the placeholders with the hub connection strings from the previous step.

+ ```azurecli-interactive

+ az iot dps linked-hub create --dps-name $DPS --resource-group $RESOURCE_GROUP --location $LOCATION --connection-string <toaster_hub_connection_string>

+ az iot dps linked-hub create --dps-name $DPS --resource-group $RESOURCE_GROUP --location $LOCATION --connection-string <heatpump_hub_connection_string>

+ ```

+1. Sign in to the [Azure portal](https://portal.azure.com).

+1. In the search box, search for and select **Function App**.

+1. Select **Create** or **Create Function App**.

+1. On the **Function App** create page, under the **Basics** tab, enter the following settings for your new function app and select **Review + create**:

+ | Parameter | Value |

+ |--|-|

+ | **Subscription** | Make sure that the subscription where you created the resources for this tutorial is selected. |

+ | **Resource Group** | Select the resource group that you created in the previous section. The default provided in the previous section is **contoso-us-resource-group**. |

+ | **Function App name** | Provide a name for your function app.|

+ | **Do you want to deploy code or container image?** | **Code** |

+ | **Runtime Stack** | **.NET** |

+ | **Version** | Select any **in-process model** version. |

+ | **Region** | Select a region close to you. |

+ > [!NOTE]

+ > By default, Application Insights is enabled. Application Insights is not necessary for this tutorial, but it might help you understand and investigate any issues you encounter with the custom allocation. If you prefer, you can disable Application Insights by selecting the **Monitoring** tab and then selecting **No** for **Enable Application Insights**.

+ :::image type="content" source="./media/tutorial-custom-allocation-policies/create-function-app.png" alt-text="Screenshot that shows the Create Function App form in the Azure portal.":::

+1. On the **Review + create** tab, select **Create** to create the function app.

+1. Deployment might take several minutes. When it completes, select **Go to resource**.

+1. On the left pane of the function app **Overview** page, select **Create function**.

+ :::image type="content" source="./media/tutorial-custom-allocation-policies/create-function-in-portal.png" alt-text="Screenshot that shows selecting the option to create function in the Azure portal.":::

+1. On the **Create function** page, select the **HTTP Trigger** template then select **Next**.

+1. On the **Template details** tab, select **Anonymous** as the **Authorization level** then select **Create**.

+ :::image type="content" source="./media/tutorial-custom-allocation-policies/function-authorization-level.png" alt-text="Screenshot that shows setting the authorization level as anonymous.":::

+ >[!TIP]

+ >If you keep the authorization level as **Function**, then you'll need to configure your DPS enrollments with the function API key. For more information, see [Azure Functions HTTP trigger](../azure-functions/functions-bindings-http-webhook-trigger.md).

+1. When the **HttpTrigger1** function opens, select **Code + Test** on the left pane. This allows you to edit the code for the function. The **run.csx** code file should be opened for editing.

+1. Reference required NuGet packages. To create the initial device twin, the custom allocation function uses classes that are defined in two NuGet packages that must be loaded into the hosting environment. With Azure Functions, NuGet packages are referenced using a *function.proj* file. In this step, you save and upload a *function.proj* file for the required assemblies. For more information, see [Using NuGet packages with Azure Functions](../azure-functions/functions-reference-csharp.md#using-nuget-packages).

+ 1. Select the **Upload** button located above the code editor to upload your *function.proj* file. After uploading, select the file in the code editor using the drop-down box to verify the contents.

+ 1. Select the *function.proj* file in the code editor and verify its contents. If the *function.proj* file is empty copy the lines above into the file and save it. (Sometimes the upload creates the file without uploading the contents.)

+1. Make sure *run.csx* for **HttpTrigger1** is selected in the code editor. Replace the code for the **HttpTrigger1** function with the following code and select **Save**:

+In this section, you create a new enrollment group that uses the custom allocation policy. For simplicity, this tutorial uses [Symmetric key attestation](concepts-symmetric-key-attestation.md) with the enrollment. For a more secure solution, consider using [X.509 certificate attestation](concepts-x509-attestation.md) with a chain of trust.

+After saving the enrollment, reopen it and make a note of the **Primary key**. You must save the enrollment first to have the keys generated. This key is used to generate unique device keys for simulated devices in the next section.

+Devices don't use the enrollment group's primary symmetric key directly. Instead, you use the primary key to derive a device key for each device. In this section, you create two unique device keys. One key is used for a simulated toaster device. The other key is used for a simulated heat pump device.

+To derive the device key, you use the enrollment group **Primary Key** you noted earlier to compute the [HMAC-SHA256](https://wikipedia.org/wiki/HMAC) of the device registration ID for each device and convert the result into Base 64 format. For more information on creating derived device keys with enrollment groups, see the group enrollments section of [Symmetric key attestation](concepts-symmetric-key-attestation.md).

+az iot dps enrollment-group compute-device-key --key <ENROLLMENT_GROUP_KEY> --registration-id breakroom499-contoso-tstrsd-007

+az iot dps compute-device-key --key <ENROLLMENT_GROUP_KEY> --registration-id mainbuilding167-contoso-hpsd-088

+The simulated devices use the derived device keys with each registration ID to perform symmetric key attestation.

+ Once the build succeeds, the last few output lines look similar to the following output:

+This sample code simulates a device boot sequence that sends the provisioning request to your Device Provisioning Service instance. The boot sequence causes the toaster device to be recognized and assigned to the IoT hub using the custom allocation policy.

+1. In the Azure portal, select the **Overview** tab for your Device Provisioning Service and note down the **ID Scope** value.

+ 

+2. In Visual Studio, open the **azure_iot_sdks.sln** solution file that was generated by running CMake earlier. The solution file should be in the following location: `azure-iot-sdk-c\cmake\azure_iot_sdks.sln`.

+4. Find the `id_scope` constant, and replace the value with your **ID Scope** value that you copied earlier.

+## Troubleshoot custom allocation policies

+2. In the **Filter by name...** textbox, type the name of the resource group containing your resources, **contoso-us-resource-group**.

+The default output log level is 'Info'. To change the output log level, set the `LogLevel` environment variable for this module in the deployment manifest. `LogLevel` accepts the following values:

+* Critical

+* Error

+* Warning

+* Info

+* Debug

+For information on configuring log files for your module, see these [production best practices](./production-checklist.md#set-up-logs-and-diagnostics).

+Azure Load Testing uses Apache JMeter version 5.6.3 for running load tests.

+## Limitations of model monitoring in Azure Machine Learning

+Azure Machine Learning model monitoring supports only the use of credential-based authentication (e.g., SAS token) to access data contained in datastores. To learn more about datastores and authentication modes, see [Data administration](how-to-administrate-data-authentication.md).

+Both managed endpoints and Kubernetes endpoints allow Azure Machine Learning to manage the burden of provisioning your compute resource and deploying your machine learning model. Typically your model needs to access Azure resources such as the Azure Container Registry or your blob storage for inferencing; with a managed identity, you can access these resources without needing to manage credentials in your code. [Learn more about managed identities](../active-directory/managed-identities-azure-resources/overview.md).

+This guide assumes you don't have a managed identity, a storage account, or an online endpoint. If you already have these components, skip to the [Give access permission to the managed identity](#give-access-permission-to-the-managed-identity) section.

+* An Azure resource group, in which you (or the service principal you use) need to have *User Access Administrator* and *Contributor* access. You have such a resource group if you configured your ML extension per the preceding article.

+* An Azure Machine Learning workspace. You already have a workspace if you configured your ML extension per the preceding article.

+* A trained machine learning model ready for scoring and deployment. If you're following along with the sample, a model is provided.

+* To follow along with the sample, clone the samples repository and then change directory to *cli*.

+* An Azure Resource group, in which you (or the service principal you use) need to have *User Access Administrator* and *Contributor* access. You have such a resource group if you configured your ML extension per the preceding article.

+* An Azure Machine Learning workspace. You have a workspace if you configured your ML extension per the above article.

+* A trained machine learning model ready for scoring and deployment. If you're following along with the sample, a model is provided.

+* To follow along with the sample, clone the samples repository and then change directory to *cli*.

+* An Azure Resource group, in which you (or the service principal you use) need to have *User Access Administrator* and *Contributor* access. You have such a resource group if you configured your ML extension per the preceding article.

+* An Azure Machine Learning workspace. You already have a workspace if you configured your ML extension per the preceding article.

+* A trained machine learning model ready for scoring and deployment. If you're following along with the sample, a model is provided.

+* Clone the samples repository, then change the directory.

+* To follow along with this notebook, access the companion [example notebook](https://github.com/Azure/azureml-examples/blob/main/sdk/python/endpoints/online/managed/managed-identities/online-endpoints-managed-identity-uai.ipynb) within in the *sdk/endpoints/online/managed/managed-identities* directory.

+* Other Python packages are required for this example:

+ * Microsoft Azure Storage Management Client

+* Role creation permissions for your subscription or the Azure resources accessed by the user-assigned identity.

+* An Azure Resource group, in which you (or the service principal you use) need to have *User Access Administrator* and *Contributor* access. You have such a resource group if you configured your ML extension per the preceding article.

+* An Azure Machine Learning workspace. You already have a workspace if you configured your ML extension per the preceding article.

+* A trained machine learning model ready for scoring and deployment. If you're following along with the sample, a model is provided.

+* To follow along with this notebook, access the companion [example notebook](https://github.com/Azure/azureml-examples/blob/main/sdk/python/endpoints/online/managed/managed-identities/online-endpoints-managed-identity-uai.ipynb) within in the *sdk/endpoints/online/managed/managed-identities* directory.

+* Other Python packages are required for this example:

+ * Microsoft Azure MSI Management Client

+* The identity for an endpoint is immutable. During endpoint creation, you can associate it with a system-assigned identity (default) or a user-assigned identity. You can't change the identity after the endpoint is created.

+* If your ARC and blob storage are configured as private, that is, behind a virtual network, then access from the Kubernetes endpoint should be over the private link regardless of whether your workspace is public or private. More details about private link setting, refer to [How to secure workspace vnet](./how-to-secure-workspace-vnet.md#azure-container-registry).

+After these variables are exported, create a text file locally. When the endpoint is deployed, the scoring script accesses this text file using the system-assigned managed identity that's generated upon endpoint creation.

+Decide on the name of your endpoint, workspace, and workspace location, then export that value as an environment variable:

+After these variables are exported, create a text file locally. When the endpoint is deployed, the scoring script accesses this text file using the user-assigned managed identity used in the endpoint.

+After these variables are assigned, create a text file locally. When the endpoint is deployed, the scoring script accesses this text file using the system-assigned managed identity that's generated upon endpoint creation.

+Use this value to create a storage account.

+After these variables are assigned, create a text file locally. When the endpoint is deployed, the scoring script accesses this text file using the user-assigned managed identity that's generated upon endpoint creation.

+Use this value to create a storage account.

+The following YAML example is located at *endpoints/online/managed/managed-identities/1-sai-create-endpoint*. The file,

+This YAML example, *2-sai-deployment.yml*,

+The following YAML example is located at *endpoints/online/managed/managed-identities/1-uai-create-endpoint*. The file,

+This YAML example, *2-sai-deployment.yml*,

+To deploy an online endpoint with the Python SDK (v2), objects can be used to define the following configuration. Alternatively, YAML files can be loaded using the `.load` method.

+* Assigns the name by which you want to refer to the endpoint to the variable `endpoint_name`.

+* Defines extra objects inline and associates them with the deployment for `Model`,`CodeConfiguration`, and `Environment`.

+To deploy an online endpoint with the Python SDK (v2), objects can be used to define the following configuration. Alternatively, YAML files can be loaded using the `.load` method.

+For a user-assigned identity, you define the endpoint configuration after the user-assigned managed identity is created.

+* Defines more objects inline and associates them with the deployment for `Model`,`CodeConfiguration`, and `Environment`.

+* Adds a placeholder environment variable for `UAI_CLIENT_ID`, which is added after creating one and before actually deploying this configuration.

+## Create the managed identity

+To create a user-assigned managed identity, use the following command:

+Now, retrieve the identity object, which contains details you use:

+For this example, create a blob storage account and blob container, and then upload the previously created text file to the blob container. You give the online endpoint and managed identity access to this storage account and blob container.

+* Assigns the name by which you want to refer to the endpoint to the variable `endpoint_name`.

+* Defines its identity as a `ManagedServiceIdentity` and specifies the Managed Identity as user assigned.

+First, make an `AuthorizationManagementClient` to list role definitions:

+Now, initialize one to make role assignments:

+Then, get the principal ID of the system-assigned managed identity:

+Next, assign the *Storage Blob Data Reader* role to the endpoint. The role definition is retrieved by name and passed along with the Principal ID of the endpoint. The role is applied at the scope of the storage account created above and allows the endpoint to read the file.

+First, make an `AuthorizationManagementClient` to list role definitions:

+Now, initialize one to make role assignments:

+Then, get the principal ID and client ID of the user-assigned managed identity. To assign roles, you only need the principal ID. However, you use the client ID to fill the `UAI_CLIENT_ID` placeholder environment variable before creating the deployment.

+Next, assign the *Storage Blob Data Reader* role to the endpoint. The role definition is retrieved by name and passed along with the principal ID of the endpoint. The role is applied at the scope of the storage account created above to allow the endpoint to read the file.

+For the next two permissions, you need the workspace and container registry objects:

+Next, assign the *AcrPull* role to the user-assigned identity. This role allows images to be pulled from an Azure Container Registry. The scope is applied at the level of the container registry associated with the workspace.

+Finally, assign the *Storage Blob Data Reader* role to the endpoint at the workspace storage account scope. This role assignment allows the endpoint to read blobs in the workspace storage account as well as the newly created storage account.

+Before you deploy, update the `UAI_CLIENT_ID` environment variable placeholder.

+When your deployment completes, the model, the environment, and the endpoint are registered to your Azure Machine Learning workspace.

+## Related content

+* [Deploy and score a machine learning model by using an online endpoint](how-to-deploy-online-endpoints.md)

+* [Perform safe rollout of new deployments for real-time inference](how-to-safely-rollout-online-endpoints.md)

+* [Install and set up the CLI (v2)](how-to-configure-cli.md)

+* [Managed online endpoints SKU list](reference-managed-online-endpoints-vm-sku-list.md)

+* [View costs for an Azure Machine Learning managed online endpoint](how-to-view-online-endpoints-costs.md)

+* [Monitor online endpoints](how-to-monitor-online-endpoints.md)

+* For limitations of managed online endpoint and Kubernetes online endpoint, see [limits for online endpoints](how-to-manage-quotas.md#azure-machine-learning-online-endpoints-and-batch-endpoints)

+The following code is an example of a full scoring script (`score.py`) that uses the custom logging Python SDK.

+### Update your scoring script to log custom unique IDs

+In addition to logging pandas DataFrames directly within your scoring script, you can log data with unique IDs of your choice. These IDs can come from your application, an external system, or you can generate them. If you don't provide a custom ID, as detailed in this section, the Data collector will autogenerate a unique `correlationid` to help you correlate your model's inputs and outputs later. If you supply a custom ID, the `correlationid` field in the logged data will contain the value of your supplied custom ID.

+1. First complete the steps in the previous section, then import the `azureml.ai.monitoring.context` package by adding the following line to your scoring script:

+ ```python

+ from azureml.ai.monitoring.context import BasicCorrelationContext

+ ```

+1. In your scoring script, instantiate a `BasicCorrelationContext` object and pass in the `id` you wish to log for that row. We recommend that this `id` be a unique ID from your system, so that you can uniquely identify each logged row from your Blob Storage. Pass this object into your `collect()` API call as a parameter:

+ ```python

+ # create a context with a custom unique id

+ artificial_context = BasicCorrelationContext(id='test')

+

+ # collect inputs data, store correlation_context

+ context = inputs_collector.collect(input_df, artificial_context)

+ ```

+1. Ensure that you pass in the context into your `outputs_collector` so that your model inputs and outputs have the same unique ID logged with them, and they can be easily correlated later:

+ ```python

+ # collect outputs data, pass in context so inputs and outputs data can be correlated later

+ outputs_collector.collect(output_df, context)

+ ```

+The following code is an example of a full scoring script (`score.py`) that logs custom unique IDs.

+```python

+import pandas as pd

+import json

+from azureml.ai.monitoring import Collector

+from azureml.ai.monitoring.context import BasicCorrelationContext

+def init():

+ global inputs_collector, outputs_collector, inputs_outputs_collector

+ # instantiate collectors with appropriate names, make sure align with deployment spec

+ inputs_collector = Collector(name='model_inputs')

+ outputs_collector = Collector(name='model_outputs')

+def run(data):

+ # json data: { "data" : { "col1": [1,2,3], "col2": [2,3,4] } }

+ pdf_data = preprocess(json.loads(data))

+

+ # tabular data: { "col1": [1,2,3], "col2": [2,3,4] }

+ input_df = pd.DataFrame(pdf_data)

+ # create a context with a custom unique id

+ artificial_context = BasicCorrelationContext(id='test')

+ # collect inputs data, store correlation_context

+ context = inputs_collector.collect(input_df, artificial_context)

+ # perform scoring with pandas Dataframe, return value is also pandas Dataframe

+ output_df = predict(input_df)

+ # collect outputs data, pass in context so inputs and outputs data can be correlated later

+ outputs_collector.collect(output_df, context)

+

+ return output_df.to_dict()

+

+def preprocess(json_data):

+ # preprocess the payload to ensure it can be converted to pandas DataFrame

+ return json_data["data"]

+def predict(input_df):

+ # process input and return with outputs

+ ...

+

+ return output_df

+```

+#### Collect data for model performance monitoring

+If you want to use your collected data for model performance monitoring, it's important that each logged row has a unique `correlationid` that can be used to correlate the data with ground truth data, when such data becomes available. The data collector will autogenerate a unique `correlationid` for each logged row and include this autogenerated ID in the `correlationid` field in the JSON object. For more information on the JSON schema, see [store collected data in blob storage](#store-collected-data-in-blob-storage).

+If you want to use your own unique ID for logging with your production data, we recommend that you log this ID as a separate column in your pandas DataFrame, since the [data collector batches requests](#data-collector-batching) that are in close proximity to one another. By logging the `correlationid` as a separate column, it will be readily available downstream for integration with ground truth data.

+Before you can create your deployment with the updated scoring script, you need to create your environment with the base image `mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04` and the appropriate conda dependencies. Thereafter, you can build the environment, using the specification in the following YAML.

+## Perform payload logging

+In addition to custom logging with the provided Python SDK, you can collect request and response HTTP payload data directly without the need to augment your scoring script (`score.py`).

+1. To enable payload logging, in your deployment YAML, use the names `request` and `response`:

+ ```yml

+ $schema: http://azureml/sdk-2-0/OnlineDeployment.json

+

+ endpoint_name: my_endpoint

+ name: blue

+ model: azureml:my-model-m1:1

+ environment: azureml:env-m1:1

+ data_collector:

+ collections:

+ request:

+ enabled: 'True'

+ response:

+ enabled: 'True'

+ ```

+1. Deploy the model with payload logging enabled:

+ ```bash

+ $ az ml online-deployment create -f deployment.YAML

+ ```

+With payload logging, the collected data is not guaranteed to be in tabular format. Therefore, if you want to use collected payload data with model monitoring, you'll be required to provide a preprocessing component to make the data tabular. If you're interested in a seamless model monitoring experience, we recommend using the [custom logging Python SDK](#perform-custom-logging-for-model-monitoring).

+As your deployment is used, the collected data flows to your workspace Blob storage. The following JSON code is an example of an HTTP _request_ collected:

+```json

+{"specversion":"1.0",

+"id":"19790b87-a63c-4295-9a67-febb2d8fbce0",

+"source":"/subscriptions/d511f82f-71ba-49a4-8233-d7be8a3650f4/resourceGroups/mire2etesting/providers/Microsoft.MachineLearningServices/workspaces/mirmasterenvws/onlineEndpoints/localdev-endpoint/deployments/localdev",

+"type":"azureml.inference.request",

+"datacontenttype":"application/json",

+"time":"2022-05-25T08:59:48Z",

+"data":{"data": [ [1,2,3,4,5,6,7,8,9,10], [10,9,8,7,6,5,4,3,2,1]]},

+"path":"/score",

+"method":"POST",

+"contentrange":"bytes 0-59/*",

+"correlationid":"f6e806c9-1a9a-446b-baa2-901373162105","xrequestid":"f6e806c9-1a9a-446b-baa2-901373162105"}

+```

+And the following JSON code is another example of an HTTP _response_ collected:

+```json

+{"specversion":"1.0",

+"id":"bbd80e51-8855-455f-a719-970023f41e7d",

+"source":"/subscriptions/d511f82f-71ba-49a4-8233-d7be8a3650f4/resourceGroups/mire2etesting/providers/Microsoft.MachineLearningServices/workspaces/mirmasterenvws/onlineEndpoints/localdev-endpoint/deployments/localdev",

+"type":"azureml.inference.response",

+"datacontenttype":"application/json",

+"time":"2022-05-25T08:59:48Z",

+"data":[11055.977245525679, 4503.079536107787],

+"contentrange":"bytes 0-38/39",

+"correlationid":"f6e806c9-1a9a-446b-baa2-901373162105","xrequestid":"f6e806c9-1a9a-446b-baa2-901373162105"}

+```

+## Store collected data in blob storage

+Data collection allows you to log production inference data to a Blob storage destination of your choice. The data destination settings are configurable at the `collection_name` level.

+If the payload of your data is greater than 4 MB, there will be an event in the `{instance_id}.jsonl` file contained within the `{endpoint_name}/{deployment_name}/request/.../{instance_id}.jsonl` path that points to a raw file path, which should have the following path: `blob_url/{blob_container}/{blob_path}/{endpoint_name}/{deployment_name}/{rolled_time}/{instance_id}.jsonl`. The collected data will exist at this path.

+#### Data collector batching

+If requests are sent within short time intervals of one another, the data collector batches them together into the same JSON object. For example, if you run a script to send sample data to your endpoint, and the deployment has data collection enabled, some of the requests can get batched together, depending on the time interval between them. If you're using data collection with [Azure Machine Learning model monitoring](concept-model-monitoring.md), the model monitoring service handles each request independently. However, if you expect each logged row of data to have its own unique `correlationid`, you can include the `correlationid` as a column in the pandas DataFrame you're logging with the data collector. For more information on how you can include your unique `correlationid` as a column in the pandas DataFrame, see [Collect data for model performance monitoring](#collect-data-for-model-performance-monitoring).

+Here is an example of two logged requests that are batched together:

+```json

+{"specversion":"1.0",

+"id":"720b8867-54a2-4876-80eb-1fd6a8975770",

+"source":"/subscriptions/79a1ba0c-35bb-436b-bff2-3074d5ff1f89/resourceGroups/rg-bozhlinmomoignite/providers/Microsoft.MachineLearningServices/workspaces/momo-demo-ws/onlineEndpoints/credit-default-mdc-testing-4/deployments/main2",

+"type":"azureml.inference.model_inputs",

+"datacontenttype":"application/json",

+"time":"2024-03-05T18:16:25Z",

+"data":[{"LIMIT_BAL":502970,"AGE":54,"BILL_AMT1":308068,"BILL_AMT2":381402,"BILL_AMT3":442625,"BILL_AMT4":320399,"BILL_AMT5":322616,"BILL_AMT6":397534,"PAY_AMT1":17987,"PAY_AMT2":78764,"PAY_AMT3":26067,"PAY_AMT4":24102,"PAY_AMT5":-1155,"PAY_AMT6":2154,"SEX":2,"EDUCATION":2,"MARRIAGE":2,"PAY_0":0,"PAY_2":0,"PAY_3":0,"PAY_4":0,"PAY_5":0,"PAY_6":0},{"LIMIT_BAL":293458,"AGE":35,"BILL_AMT1":74131,"BILL_AMT2":-71014,"BILL_AMT3":59284,"BILL_AMT4":98926,"BILL_AMT5":110,"BILL_AMT6":1033,"PAY_AMT1":-3926,"PAY_AMT2":-12729,"PAY_AMT3":17405,"PAY_AMT4":25110,"PAY_AMT5":7051,"PAY_AMT6":1623,"SEX":1,"EDUCATION":3,"MARRIAGE":2,"PAY_0":-2,"PAY_2":-2,"PAY_3":-2,"PAY_4":-2,"PAY_5":-1,"PAY_6":-1}],

+"contentrange":"bytes 0-6794/6795",

+"correlationid":"test",

+"xrequestid":"test",

+"modelversion":"default",

+"collectdatatype":"pandas.core.frame.DataFrame",

+"agent":"azureml-ai-monitoring/0.1.0b4"}

+```

+1. Go to the **Data** tab in your Azure Machine Learning workspace:

+ - update-code

+[!notebook-python[] (~/azureml-examples-temp-fix/sdk/python/jobs/pipelines/2e_image_classification_keras_minist_convnet/image_classification_keras_minist_convnet.ipynb?name=define-input)]

+> Currently, UI only supports registering components with `command` type.

+ Title: Debug online endpoints locally in Visual Studio Code

+Learn how to use the Microsoft Visual Studio Code debugger to test and debug online endpoints locally before deploying them to Azure.

+Debugging endpoints locally before deploying them to the cloud can help you catch errors in your code and configuration earlier. You have different options for debugging endpoints locally with Visual Studio Code.

+| Scenario | Inference HTTP server | Local endpoint |

+| Visual Studio Code debugger integration | Yes | Yes |

+- [Visual Studio Code](https://code.visualstudio.com/#alt-downloads)

+- [Azure CLI ml extension (v2)](how-to-configure-cli.md)

+The examples in this article are based on code samples contained in the [azureml-examples](https://github.com/azure/azureml-examples) GitHub repository. To run the commands locally without having to copy/paste YAML and other files, clone the repo and then change directories to *azureml-examples/cli*:

+cd azureml-examples/cli

+> [!TIP]

+> You can see what your current defaults are by using the `az configure -l` command.

+- [Visual Studio Code](https://code.visualstudio.com/#alt-downloads)

+- [Azure CLI ml extension (v2)](how-to-configure-cli.md)

+- [Windows Subsystem for Linux (WSL)](/windows/wsl/install)

+The examples in this article can be found in the Jupyter notebook called [Debug online endpoints locally in Visual Studio Code](https://github.com/Azure/azureml-examples/blob/main/sdk/python/endpoints/online/managed/debug-online-endpoints-locally-in-visual-studio-code.ipynb) within the [azureml-examples](https://github.com/azure/azureml-examples) repository. To run the code locally, clone the repo and then change directories to the notebook's parent directory *sdk/endpoints/online/managed*.

+Open the Jupyter notebook and import the required modules:

+```

+Set up variables for the workspace and endpoint:

+```python

+```

+Azure Machine Learning local endpoints use Docker and Visual Studio Code development containers (dev containers) to build and configure a local debugging environment. With dev containers, you can take advantage of Visual Studio Code features from inside a Docker container. For more information on dev containers, see [Create a development container](https://code.visualstudio.com/docs/remote/create-dev-container).

+To debug online endpoints locally in Visual Studio Code, use the `--vscode-debug` flag when creating or updating and Azure Machine Learning online deployment. The following command uses a deployment example from the examples repo:

+> On Windows Subsystem for Linux (WSL), you'll need to update your PATH environment variable to include the path to the Visual Studio Code executable or use WSL interop. For more information, see [Windows interoperability with Linux](/windows/wsl/interop).

+> The first time you launch a new or updated dev container, it can take several minutes.

+Once the image successfully builds, your dev container opens in a Visual Studio Code window.

+You'll use a few Visual Studio Code extensions to debug your deployments in the dev container. Azure Machine Learning automatically installs these extensions in your dev container.

+> Before starting your debug session, make sure that the Visual Studio Code extensions have finished installing in your dev container.

+Azure Machine Learning local endpoints use Docker and Visual Studio Code development containers (dev containers) to build and configure a local debugging environment. With dev containers, you can take advantage of Visual Studio Code features from inside a Docker container. For more information on dev containers, see [Create a development container](https://code.visualstudio.com/docs/remote/create-dev-container).

+Get a handle to the workspace:

+```python

+```

+To debug online endpoints locally in Visual Studio Code, set the `vscode-debug` and `local` flags when creating or updating an Azure Machine Learning online deployment. The following code mirrors a deployment example from the examples repo:

+> On Windows Subsystem for Linux (WSL), you'll need to update your PATH environment variable to include the path to the Visual Studio Code executable or use WSL interop. For more information, see [Windows interoperability with Linux](/windows/wsl/interop).

+> It can take several minutes to launch a new or updated dev container for the first time.

+Once the image successfully builds, your dev container opens in a Visual Studio Code window.

+You'll use a few Visual Studio Code extensions to debug your deployments in the dev container. Azure Machine Learning automatically installs these extensions in your dev container.

+> Before starting your debug session, make sure that the Visual Studio Code extensions have finished installing in your dev container.

+Once your environment is set up, use the Visual Studio Code debugger to test and debug your deployment locally.

+ > The *score.py* script used by the endpoint deployed earlier is located at *azureml-samples/cli/endpoints/online/managed/sample/score.py* in the repository you cloned. However, the steps in this guide work with any scoring script.

+1. Select the Visual Studio Code Job view.

+1. In the **Run and Debug** dropdown, select **AzureML: Debug Local Endpoint** to start debugging your endpoint locally.

+ :::image type="content" source="media/how-to-debug-managed-online-endpoints-visual-studio-code/configure-debug-profile.png" alt-text="Screenshot showing how to configure Azure Machine Learning Debug Local Environment debug profile." lightbox="media/how-to-debug-managed-online-endpoints-visual-studio-code/configure-debug-profile.png":::

+1. Select the play icon next to the **Run and Debug** dropdown to start your debugging session.

+For more information on the Visual Studio Code debugger, see [Debugging](https://code.visualstudio.com/Docs/editor/debugging).

+1. Update your code.

+For more extensive changes involving updates to your environment and endpoint configuration, use the `ml` extension `update` command. Doing so triggers a full image rebuild with your changes.

+Once the updated image is built and your development container launches, use the Visual Studio Code debugger to test and troubleshoot your updated endpoint.

+1. Update your code.

+For more extensive changes involving updates to your environment and endpoint configuration, use your `MLClient`'s `online_deployments.update` module/method. Doing so triggers a full image rebuild with your changes.

+Once the updated image is built and your development container launches, use the Visual Studio Code debugger to test and troubleshoot your updated endpoint.

+## Related content

+- [Deploy and score a machine learning model by using an online endpoint](how-to-deploy-online-endpoints.md)

+- [Troubleshooting online endpoints deployment and scoring](how-to-troubleshoot-managed-online-endpoints.md)

+Learn how to use a custom container to deploy a model to an online endpoint in Azure Machine Learning.

+|Example|Script (CLI)|Description|

+|[tfserving/half-plus-two](https://github.com/Azure/azureml-examples/blob/main/cli/endpoints/online/custom-container/tfserving/half-plus-two)|[deploy-custom-container-tfserving-half-plus-two](https://github.com/Azure/azureml-examples/blob/main/cli/deploy-custom-container-tfserving-half-plus-two.sh)|Deploy a Half Plus Two model using a TensorFlow Serving custom container using the standard model registration process.|

+|[tfserving/half-plus-two-integrated](https://github.com/Azure/azureml-examples/blob/main/cli/endpoints/online/custom-container/tfserving/half-plus-two-integrated)|[deploy-custom-container-tfserving-half-plus-two-integrated](https://github.com/Azure/azureml-examples/blob/main/cli/deploy-custom-container-tfserving-half-plus-two-integrated.sh)|Deploy a Half Plus Two model using a TensorFlow Serving custom container with the model integrated into the image.|

+> Microsoft might not be able to help troubleshoot problems caused by a custom image. If you encounter problems, you might be asked to use the default image or one of the images Microsoft provides to see if the problem is specific to your image.

+* You, or the service principal you use, must have *Contributor* access to the Azure resource group that contains your workspace. You have such a resource group if you configured your workspace using the quickstart article.

+* To deploy locally, you must have [Docker engine](https://docs.docker.com/engine/install/) running locally. This step is **highly recommended**. It helps you debug issues.

+To follow along with this tutorial, clone the source code from GitHub.

+cd azureml-examples/cli

+See also [the example notebook](https://github.com/Azure/azureml-examples/blob/main/sdk/python/endpoints/online/custom-container/online-endpoints-custom-container.ipynb), but note that `3. Test locally` section in the notebook assumes that it runs under the `azureml-examples/sdk` directory.

+First, check that the container is *alive*, meaning that the process inside the container is still running. You should get a 200 (OK) response.

+Now that you tested locally, stop the image:

+Connect to your Azure Machine Learning workspace, configure workspace details, and get a handle to the workspace as follows:

+A deployment is a set of resources required for hosting the model that does the actual inferencing. Create a deployment for our endpoint using the `ManagedOnlineDeployment` class.

+An HTTP server defines paths for both _liveness_ and _readiness_. A liveness route is used to check whether the server is running. A readiness route is used to check whether the server is ready to do work. In machine learning inference, a server could respond 200 OK to a liveness request before loading a model. The server could respond 200 OK to a readiness request only after the model is loaded into memory.

+For more information about liveness and readiness probes, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).

+When you deploy a model as an online endpoint, Azure Machine Learning _mounts_ your model to your endpoint. Model mounting allows you to deploy new versions of the model without having to create a new Docker image. By default, a model registered with the name *foo* and version *1* would be located at the following path inside of your deployed container: */var/azureml-app/azureml-models/foo/1*

+For example, if you have a directory structure of */azureml-examples/cli/endpoints/online/custom-container* on your local machine, where the model is named *half_plus_two*:

+And *tfserving-deployment.yml* contains:

+And `Model` class contains:

+Then your model will be located under */var/azureml-app/azureml-models/tfserving-deployment/1* in your deployment:

+You can optionally configure your `model_mount_path`. It lets you change the path where the model is mounted.

+For example, you can have `model_mount_path` parameter in your *tfserving-deployment.yml*:

+Then your model is located at */var/tfserving-model-mount/tfserving-deployment/1* in your deployment. Note that it's no longer under *azureml-app/azureml-models*, but under the mount path you specified:

+Now that you understand how the YAML was constructed, create your endpoint.

+Creating a deployment might take a few minutes.

+Using the `MLClient` created earlier, create the endpoint in the workspace. This command starts the endpoint creation and returns a confirmation response while the endpoint creation continues.

+Create the deployment by running:

+Using the `MLClient` created earlier, you get a handle to the endpoint. The endpoint can be invoked using the `invoke` command with the following parameters:

+Send a sample request using a JSON file. The sample JSON is in the [example repository](https://github.com/Azure/azureml-examples/tree/main/sdk/python/endpoints/online/custom-container).

+Now that you successfully scored with your endpoint, you can delete it:

+## Related content

+This guide explains how to create deployments that generate custom outputs and files. Sometimes you need more control over what's written as output from batch inference jobs. These cases include the following situations:

+> * You need to control how predictions are written in the output. For instance, you want to append the prediction to the original data if the data is tabular.

+> * You need to write your predictions in a different file format than the one supported out-of-the-box by batch deployments.

+> * Your model produces multiple tabular files instead of a single one. For example, models that perform forecasting by considering multiple scenarios.

+Batch deployments allow you to take control of the output of the jobs by letting you write directly to the output of the batch deployment job. In this tutorial, you learn how to deploy a model to perform batch inference and write the outputs in *parquet* format by appending the predictions to the original input data.

+This example shows how you can deploy a model to perform batch inference and customize how your predictions are written in the output. The model is based on the [UCI Heart Disease dataset](https://archive.ics.uci.edu/ml/datasets/Heart+Disease). The database contains 76 attributes, but this example uses a subset of 14 of them. The model tries to predict the presence of heart disease in a patient. It's integer valued from 0 (no presence) to 1 (presence).

+The model was trained using an `XGBBoost` classifier and all the required preprocessing was packaged as a `scikit-learn` pipeline, making this model an end-to-end pipeline that goes from raw data to predictions.

+### Follow along in a Jupyter notebook

+There's a Jupyter notebook that you can use to follow this example. In the cloned repository, open the notebook called [custom-output-batch.ipynb](https://github.com/Azure/azureml-examples/blob/main/sdk/python/endpoints/batch/deploy-models/custom-outputs-parquet/custom-output-batch.ipynb).

+## Create a batch deployment with a custom output

+In this example, you create a deployment that can write directly to the output folder of the batch deployment job. The deployment uses this feature to write custom parquet files.

+### Register the model

+You can only deploy registered models using a batch endpoint. In this case, you already have a local copy of the model in the repository, so you only need to publish the model to the registry in the workspace. You can skip this step if the model you're trying to deploy is already registered.

+### Create a scoring script

+You need to create a scoring script that can read the input data provided by the batch deployment and return the scores of the model. You're also going to write directly to the output folder of the job. In summary, the proposed scoring script does as follows:

+* The `init()` function populates a global variable called `output_path` that can be used later to know where to write.

+* The `run` method returns a list of the processed files. It's required for the `run` function to return a `list` or a `pandas.DataFrame` object.

+> Take into account that all the batch executors have write access to this path at the same time. This means that you need to account for concurrency. In this case, ensure that each executor writes its own file by using the input file name as the name of the output folder.

+## Create the endpoint

+You now create a batch endpoint named `heart-classifier-batch` where the model is deployed.

+1. Decide on the name of the endpoint. The name of the endpoint appears in the URI associated with your endpoint, so *batch endpoint names need to be unique within an Azure region*. For example, there can be only one batch endpoint with the name `mybatchendpoint` in `westus2`.

+ In this case, place the name of the endpoint in a variable so you can easily reference it later.

+ In this case, place the name of the endpoint in a variable so you can easily reference it later.

+1. Configure your batch endpoint.

+### Create the deployment

+1. First, create an environment where the scoring script can be executed:

+ No extra step is required for the Azure Machine Learning CLI. The environment definition is included in the deployment file.

+ Get a reference to the environment:

+2. Create the deployment. Notice that `output_action` is now set to `SUMMARY_ONLY`.

+ > This example assumes you have a compute cluster with name `batch-cluster`. Change that name accordingly.

+ To create a new deployment under the created endpoint, create a YAML configuration like the following. You can check the [full batch endpoint YAML schema](reference-yaml-endpoint-batch.md) for extra properties.

+## Test the deployment

+To test your endpoint, use a sample of unlabeled data located in this repository, which can be used with the model. Batch endpoints can only process data that's located in the cloud and is accessible from the Azure Machine Learning workspace. In this example, you upload it to an Azure Machine Learning data store. You're going to create a data asset that can be used to invoke the endpoint for scoring. However, notice that batch endpoints accept data that can be placed in multiple type of locations.

+1. Invoke the endpoint with data from a storage account:

+ > The utility `jq` might not be installed on every installation. You can [get instructions](https://jqlang.github.io/jq/download) on GitHub.

+## Analyze the outputs

+The job generates a named output called `score` where all the generated files are placed. Since you wrote into the directory directly, one file per each input file, then you can expect to have the same number of files. In this particular example, name the output files the same as the inputs, but they have a parquet extension.

+> Notice that a file *predictions.csv* is also included in the output folder. This file contains the summary of the processed files.

+Run the following code to delete the batch endpoint and all the underlying deployments. Batch scoring jobs aren't deleted.

+Run the following code to delete the batch endpoint and all the underlying deployments. Batch scoring jobs aren't deleted.

+## Related content

+* [Image processing with batch model deployments](how-to-image-processing-batch.md)

+* [Deploy language models in batch endpoints](how-to-nlp-processing-batch.md)

+> To get all metrics logged for a particular metric name, you can use `MlFlowClient.get_metric_history()` as explained in the example [Getting params and metrics from a run](how-to-track-experiments-mlflow.md#get-params-and-metrics-from-a-run).

+For more information, please refer to [Getting metrics, parameters, artifacts and models](how-to-track-experiments-mlflow.md#get-metrics-parameters-artifacts-and-models).

+Learn to use Azure Machine Learning's model monitoring to continuously track the performance of machine learning models in production. Model monitoring provides you with a broad view of monitoring signals and alerts you to potential issues. When you monitor signals and performance metrics of models in production, you can critically evaluate the inherent risks associated with them and identify blind spots that could adversely affect your business.

+In this article you, learn to perform the following tasks:

+> [!div class="checklist"]

+> * Set up out-of box and advanced monitoring for models that are deployed to Azure Machine Learning online endpoints

+> * Monitor performance metrics for models in production

+> * Monitor models that are deployed outside Azure Machine Learning or deployed to Azure Machine Learning batch endpoints

+> * Set up model monitoring with custom signals and metrics

+> * Interpret monitoring results

+> * Integrate Azure Machine Learning model monitoring with Azure Event Grid

+ BaselineDataRange,

+ FeatureAttributionDriftMetricThreshold,

+ FeatureAttributionDriftSignal,

+ ReferenceData,

+ ProductionData

+# specify a lookback window size and offset, or omit this to use the defaults, which are specified in the documentation

+data_window = BaselineDataRange(lookback_window_size="P1D", lookback_window_offset="P0D")

+production_data = ProductionData(

+ input_data=Input(

+ type="uri_folder",

+ path="azureml:credit-default-main-model_inputs:1"

+ ),

+ data_window=data_window,

+ data_context=MonitorDatasetContext.MODEL_INPUTS,

+)

+ data_column_names={

+ "target_column":"DEFAULT_NEXT_MONTH"

+ },

+# create feature attribution drift signal

+metric_thresholds = FeatureAttributionDriftMetricThreshold(normalized_discounted_cumulative_gain=0.9)

+feature_attribution_drift = FeatureAttributionDriftSignal(

+ reference_data=reference_data_training,

+ metric_thresholds=metric_thresholds,

+ alert_enabled=False

+)

+ 'data_quality_advanced':advanced_data_quality,

+ 'feature_attribution_drift':feature_attribution_drift,

+ :::image type="content" source="media/how-to-monitor-models/model-monitoring-advanced-configuration-data.png" alt-text="Screenshot showing how to add datasets for the monitoring signals to use." lightbox="media/how-to-monitor-models/model-monitoring-advanced-configuration-data.png":::

+1. Configure the data drift in the **Edit signal** window as follows:

+ 1. In step 1, for the production data asset, select your model inputs dataset. Also, make the following selection:

+ - Select the desired lookback window size.

+ 1. In step 2, for the reference data asset, select your training dataset. Also, make the following selection:

+ - Select the target (output) column.

+ 1. In step 3, select to monitor drift for the top N most important features, or monitor drift for a specific set of features.

+ 1. In step 4, select your preferred metric and thresholds to use for numerical features.

+ 1. In step 5, select your preferred metric and thresholds to use for categorical features.

+ 1. In step 1, select the production data asset that has your model inputs

+ - Also, select the desired lookback window size.

+ 1. In step 2, select the production data asset that has your model outputs.

+ - Also, select the common column between these data assets to join them on. If the data was collected with the [data collector](how-to-collect-production-data.md), the common column is `correlationid`.

+ 1. (Optional) If you used the data collector to collect data that has your model inputs and outputs already joined, select the joined dataset as your production data asset (in step 1)

+ - Also, **Remove** step 2 in the configuration panel.

+ 1. In step 3, select your training dataset to use as the reference dataset.

+ - Also, select the target (output) column for your training dataset.

+ 1. In step 4, select your preferred metric and threshold.

+ :::image type="content" source="media/how-to-monitor-models/model-monitoring-advanced-configuration-review.png" alt-text="Screenshot showing review page of the advanced configuration for model monitoring." lightbox="media/how-to-monitor-models/model-monitoring-advanced-configuration-review.png":::

+## Set up model performance monitoring

+Azure Machine Learning model monitoring enables you to track the performance of your models in production by calculating their performance metrics. The following model performance metrics are currently supported:

+For classification models:

+- Precision

+- Accuracy

+- Recall

+For regression models:

+- Mean Absolute Error (MAE)

+- Mean Squared Error (MSE)

+- Root Mean Squared Error (RMSE)

+### More prerequisites for model performance monitoring

+You must satisfy the following requirements for you to configure your model performance signal:

+* Have output data for the production model (the model's predictions) with a unique ID for each row. If you collect production data with the [Azure Machine Learning data collector](how-to-collect-production-data.md), a `correlation_id` is provided for each inference request for you. With the data collector, you also have the option to log your own unique ID from your application.

+ > [!NOTE]

+ >

+ > For Azure Machine Learning model performance monitoring, we recommend that you log your unique ID in its own column, using the [Azure Machine Learning data collector](how-to-collect-production-data.md).

+* Have ground truth data (actuals) with a unique ID for each row. The unique ID for a given row should match the unique ID for the model outputs for that particular inference request. This unique ID is used to join your ground truth dataset with the model outputs.

+ Without having ground truth data, you can't perform model performance monitoring. Since ground truth data is encountered at the application level, it's your responsibility to collect it as it becomes available. You should also maintain a data asset in Azure Machine Learning that contains this ground truth data.

+* (Optional) Have a pre-joined tabular dataset with model outputs and ground truth data already joined together.

+### Monitor model performance requirements when using data collector

+If you use the [Azure Machine Learning data collector](concept-data-collection.md) to collect production inference data without supplying your own unique ID for each row as a separate column, a `correlationid` will be autogenerated for you and included in the logged JSON object. However, the data collector will [batch rows](how-to-collect-production-data.md#data-collector-batching) that are sent within short time intervals of each other. Batched rows will fall within the same JSON object and will thus have the same `correlationid`.

+In order to differentiate between the rows in the same JSON object, Azure Machine Learning model performance monitoring uses indexing to determine the order of the rows in the JSON object. For example, if three rows are batched together, and the `correlationid` is `test`, row one will have an ID of `test_0`, row two will have an ID of `test_1`, and row three will have an ID of `test_2`. To ensure that your ground truth dataset contains unique IDs that match to the collected production inference model outputs, ensure that you index each `correlationid` appropriately. If your logged JSON object only has one row, then the `correlationid` would be `correlationid_0`.

+To avoid using this indexing, we recommend that you log your unique ID in its own column within the pandas DataFrame that you're logging with the [Azure Machine Learning data collector](how-to-collect-production-data.md). Then, in your model monitoring configuration, you specify the name of this column to join your model output data with your ground truth data. As long as the IDs for each row in both datasets are the same, Azure Machine Learning model monitoring can perform model performance monitoring.

+### Example workflow for monitoring model performance

+To understand the concepts associated with model performance monitoring, consider this example workflow. Suppose you're deploying a model to predict whether credit card transactions are fraudulent or not, you can follow these steps to monitor the model's performance:

+1. Configure your deployment to use the data collector to collect the model's production inference data (input and output data). Let's say that the output data is stored in a column `is_fraud`.

+1. For each row of the collected inference data, log a unique ID. The unique ID can come from your application, or you can use the `correlationid` that Azure Machine Learning uniquely generates for each logged JSON object.

+1. Later, when the ground truth (or actual) `is_fraud` data becomes available, it also gets logged and mapped to the same unique ID that was logged with the model's outputs.

+1. This ground truth `is_fraud` data is also collected, maintained, and registered to Azure Machine Learning as a data asset.

+1. Create a model performance monitoring signal that joins the model's production inference and ground truth data assets, using the unique ID columns.

+1. Finally, compute the model performance metrics.

+# [Azure CLI](#tab/azure-cli)

+Once you've satisfied the [prerequisites for model performance monitoring](#more-prerequisites-for-model-performance-monitoring), you can set up model monitoring with the following CLI command and YAML definition:

+```azurecli

+az ml schedule create -f ./model-performance-monitoring.yaml

+```

+The following YAML contains the definition for model monitoring with production inference data that you've collected.

+```YAML

+$schema: http://azureml/sdk-2-0/Schedule.json

+name: model_performance_monitoring

+display_name: Credit card fraud model performance

+description: Credit card fraud model performance

+trigger:

+ type: recurrence

+ frequency: day

+ interval: 7

+ schedule:

+ hours: 10

+ minutes: 15

+

+create_monitor:

+ compute:

+ instance_type: standard_e8s_v3

+ runtime_version: "3.3"

+ monitoring_target:

+ ml_task: classification

+ endpoint_deployment_id: azureml:loan-approval-endpoint:loan-approval-deployment

+ monitoring_signals:

+ fraud_detection_model_performance:

+ type: model_performance

+ production_data:

+ data_column_names:

+ prediction: is_fraud

+ correlation_id: correlation_id

+ reference_data:

+ input_data:

+ path: azureml:my_model_ground_truth_data:1

+ type: mltable

+ data_column_names:

+ actual: is_fraud

+ correlation_id: correlation_id

+ data_context: actuals

+ alert_enabled: true

+ metric_thresholds:

+ tabular_classification:

+ accuracy: 0.95

+ precision: 0.8

+ alert_notification:

+ emails:

+ - abc@example.com

+```

+# [Python SDK](#tab/python)

+Once you've satisfied the [prerequisites for model performance monitoring](#more-prerequisites-for-model-performance-monitoring), you can set up model monitoring with the following Python code:

+```python

+from azure.identity import DefaultAzureCredential

+from azure.ai.ml import Input, MLClient

+from azure.ai.ml.constants import (

+ MonitorDatasetContext,

+)

+from azure.ai.ml.entities import (

+ AlertNotification,

+ BaselineDataRange,

+ ModelPerformanceMetricThreshold,

+ ModelPerformanceSignal,

+ ModelPerformanceClassificationThresholds,

+ MonitoringTarget,

+ MonitorDefinition,

+ MonitorSchedule,

+ RecurrencePattern,

+ RecurrenceTrigger,

+ ServerlessSparkCompute,

+ ReferenceData,

+ ProductionData

+)

+# get a handle to the workspace

+ml_client = MLClient(

+ DefaultAzureCredential(),

+ subscription_id="subscription_id",

+ resource_group_name="resource_group_name",

+ workspace_name="workspace_name",

+)

+# create your compute

+spark_compute = ServerlessSparkCompute(

+ instance_type="standard_e4s_v3",

+ runtime_version="3.3"

+)

+# reference your azureml endpoint and deployment

+monitoring_target = MonitoringTarget(

+ ml_task="classification",

+)

+# MDC-generated production data with data column names

+production_data = ProductionData(

+ input_data=Input(

+ type="uri_folder",

+ path="azureml:credit-default-main-model_outputs:1"

+ ),

+ data_column_names={

+ "target_column": "DEFAULT_NEXT_MONTH",

+ "join_column": "correlationid"

+ },

+ data_window=BaselineDataRange(

+ lookback_window_offset="P0D",

+ lookback_window_size="P10D",

+ )

+)

+# ground truth reference data

+reference_data_ground_truth = ReferenceData(

+ input_data=Input(

+ type="mltable",

+ path="azureml:credit-ground-truth:1"

+ ),

+ data_column_names={

+ "target_column": "ground_truth",

+ "join_column": "correlationid"

+ },

+ data_context=MonitorDatasetContext.GROUND_TRUTH_DATA,

+)

+# create the model performance signal

+metric_thresholds = ModelPerformanceMetricThreshold(

+ classification=ModelPerformanceClassificationThresholds(

+ accuracy=0.50,

+ precision=0.50,

+ recall=0.50

+ ),

+)

+model_performance = ModelPerformanceSignal(

+ production_data=production_data,

+ reference_data=reference_data_ground_truth,

+ metric_thresholds=metric_thresholds

+)

+# put all monitoring signals in a dictionary

+monitoring_signals = {

+ 'model_performance':model_performance,

+}

+# create alert notification object

+alert_notification = AlertNotification(

+ emails=['abc@example.com', 'def@example.com']

+)

+# Finally monitor definition

+monitor_definition = MonitorDefinition(

+ compute=spark_compute,

+ monitoring_target=monitoring_target,

+ monitoring_signals=monitoring_signals,

+ alert_notification=alert_notification

+)

+recurrence_trigger = RecurrenceTrigger(

+ frequency="day",

+ interval=1,

+ schedule=RecurrencePattern(hours=3, minutes=15)

+)

+model_monitor = MonitorSchedule(

+ name="credit_default_model_performance",

+ trigger=recurrence_trigger,

+ create_monitor=monitor_definition

+)

+poller = ml_client.schedules.begin_create_or_update(model_monitor)

+created_monitor = poller.result()

+```

+# [Studio](#tab/azure-studio)

+To set up model performance monitoring:

+1. Complete the entries on the **Basic settings** page as described earlier in the [Set up out-of-box model monitoring](#set-up-out-of-box-model-monitoring) section.

+1. Select **Next** to open the **Configure data asset** page of the **Advanced settings** section.

+1. Select **+ Add** to add a dataset for use as the ground truth dataset.

+ Ensure that your model outputs dataset is also included in the list of added datasets. The ground truth dataset you add should have a unique ID column.

+ The values in the unique ID column for both the ground truth dataset and the model outputs dataset must match in order for both datasets to be joined together prior to metric computation.

+ :::image type="content" source="media/how-to-monitor-models/model-monitoring-advanced-configuration-data-2.png" alt-text="Screenshot showing how to add datasets to use for model performance monitoring." lightbox="media/how-to-monitor-models/model-monitoring-advanced-configuration-data-2.png":::

+ :::image type="content" source="media/how-to-monitor-models/model-monitoring-added-ground-truth-dataset.png" alt-text="Screenshot showing the ground truth dataset and the model outputs and inputs datasets for the monitoring signals to connect to." lightbox="media/how-to-monitor-models/model-monitoring-added-ground-truth-dataset.png":::

+1. Select **Next** to go to the **Select monitoring signals** page. On this page, you will see some monitoring signals already added (if you selected an Azure Machine Learning online deployment earlier).

+1. Delete the existing monitoring signals on the page, since you're only interested in creating a model performance monitoring signal.

+1. Select **Add** to open the **Edit Signal** window.

+1. Select **Model performance (preview)** to configure the model performance signal as follows:

+ 1. In step 1, for the production data asset, select your model outputs dataset. Also, make the following selections:

+ - Select the appropriate target column (for example, `is_fraud`).

+ - Select the desired lookback window size and lookback window offset.

+ 1. In step 2, for the reference data asset, select the ground truth data asset that you added earlier. Also, make the following selections:

+ - Select the appropriate target column.

+ - Select the column on which to perform the join with the model outputs dataset. The column used for the join should be the column that is common between the two datasets and which has a unique ID for each row in the dataset (for example, `correlationid`).

+ 1. In step 3, select your desired performance metrics and specify their respective thresholds.

+ :::image type="content" source="media/how-to-monitor-models/model-monitoring-configure-model-performance.png" alt-text="Screenshot showing how to configure a model performance signal." lightbox="media/how-to-monitor-models/model-monitoring-configure-model-performance.png":::

+1. Select **Save** to return to the **Select monitoring signals** page.

+ :::image type="content" source="media/how-to-monitor-models/model-monitoring-configured-model-performance-signal.png" alt-text="Screenshot showing the configured model performance signal." lightbox="media/how-to-monitor-models/model-monitoring-configured-model-performance-signal.png":::

+1. Select **Next** to go to the **Notifications** page.

+1. On the **Notifications** page, enable alert notification for the model performance signal and select **Next**.

+1. Review your settings on the **Review monitoring settings** page.

+ :::image type="content" source="media/how-to-monitor-models/model-monitoring-review-monitoring-details.png" alt-text="Screenshot showing review page that includes the configured model performance signal." lightbox="media/how-to-monitor-models/model-monitoring-review-monitoring-details.png":::

+1. Select **Create** to create your model performance monitor.

+## Set up model monitoring by bringing in your production data to Azure Machine Learning

+With Azure Machine Learning model monitoring, you can define a custom signal and implement any metric of your choice to monitor your model. You can register this custom signal as an Azure Machine Learning component. When your Azure Machine Learning model monitoring job runs on the specified schedule, it computes the metric(s) you've defined within your custom signal, just as it does for the prebuilt signals (data drift, prediction drift, and data quality).

+ > [!IMPORTANT]

+ > Registry only support to have named assets (data/model/component/environment). If you to reference an asset in a registry, you need to create it in the registry first. Especially for pipeline component case, if you want reference component or environment in pipeline component, you need first create the component or environment in the registry.

+description: Learn how to use MLflow for managing experiments and runs in Azure Machine Learning.

+* Create, query, delete, and search for experiments in a workspace.

+* Track and retrieve metrics, parameters, artifacts, and models from runs.

+For a detailed comparison between open-source MLflow and MLflow when connected to Azure Machine Learning, see [Support matrix for querying runs and experiments in Azure Machine Learning](#support-matrix-for-querying-runs-and-experiments).

+You can also query and search experiments and runs by using the MLflow REST API. See [Using MLflow REST with Azure Machine Learning](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/using-rest-api/using_mlflow_rest_api.ipynb) for an example about how to consume it.

+## Prerequisites

+ > In legacy versions of MLflow (<2.0), use method `mlflow.list_experiments()` instead.

+### Search experiments

+The `search_experiments()` method, available since Mlflow 2.0, lets you search for experiments that match criteria using `filter_string`.

+MLflow lets you search for runs inside any experiment, including multiple experiments at the same time. The method `mlflow.search_runs()` accepts the argument `experiment_ids` and `experiment_name` to indicate which experiments you want to search. You can also indicate `search_all_experiments=True` if you want to search across all the experiments in the workspace:

+Notice that `experiment_ids` supports providing an array of experiments, so you can search runs across multiple experiments, if necessary. This might be useful in case you want to compare runs of the same model when it's being logged in different experiments (for example, by different people or different project iterations).

+> If `experiment_ids`, `experiment_names`, or `search_all_experiments` aren't specified, then MLflow searches by default in the current active experiment. You can set the active experiment using `mlflow.set_experiment()`.

+All metrics and parameters are also returned when querying runs. However, for metrics that contain multiple values (for instance, a loss curve, or a PR curve), only the last value of the metric is returned. If you want to retrieve all the values of a given metric, uses `mlflow.get_metric_history` method. See [Getting params and metrics from a run](#get-params-and-metrics-from-a-run) for an example.

+### Order runs

+By default, experiments are in descending order by `start_time`, which is the time the experiment was queued in Azure Machine Learning. However, you can change this default by using the parameter `order_by`.

+ > `attributes.duration` isn't present in MLflow OSS, but provided in Azure Machine Learning for convenience.

+ > Using `order_by` with expressions containing `metrics.*`, `params.*`, or `tags.*` in the parameter `order_by` isn't currently supported. Instead, use the `order_values` method from Pandas as shown in the example.

+### Filter runs

+You can also look for a run with a specific combination in the hyperparameters using the parameter `filter_string`. Use `params` to access run's parameters, `metrics` to access metrics logged in the run, and `attributes` to access run information details. MLflow supports expressions joined by the AND keyword (the syntax doesn't support OR):

+* Search runs that failed. See [Filter runs by status](#filter-runs-by-status) for possible values:

+ > For the key `attributes`, values should always be strings and hence encoded between quotes.

+* Search runs that take longer than one hour:

+ > `attributes.duration` isn't present in MLflow OSS, but provided in Azure Machine Learning for convenience.

+* Search runs that have the ID in a given set:

+When you filter runs by status, MLflow uses a different convention to name the different possible status of a run compared to Azure Machine Learning. The following table shows the possible values:

+| Azure Machine Learning job status | MLFlow's `attributes.status` | Meaning |

+| :-: | :-: | :-: |

+| Preparing | `Scheduled` | The job/run hasn't started yet, but a compute was allocated for its execution and it's preparing the environment and its inputs. |

+| Completed | `Finished` | The job/run was completed without errors. |

+| Failed | `Failed` | The job/run was completed with errors. |

+| Canceled | `Killed` | The job/run was canceled by the user or terminated by the system. |

+## Get metrics, parameters, artifacts, and models

+The method `search_runs` returns a Pandas `Dataframe` that contains a limited amount of information by default. You can get Python objects if needed, which might be useful to get details about them. Use the `output_format` parameter to control how output is returned:

+### Get params and metrics from a run

+### Get artifacts from a run

+MLflow can query any artifact logged by a run. Artifacts can't be accessed using the run object itself, and the MLflow client should be used instead:

+The preceding method lists all the artifacts logged in the run, but they remain stored in the artifacts store (Azure Machine Learning storage). To download any of them, use the method `download_artifact`:

+### Get models from a run

+Models can also be logged in the run and then retrieved directly from it. To retrieve a model, you need to know the path to the artifact where it's stored. The method `list_artifacts` can be used to find artifacts that represent a model since MLflow models are always folders. You can download a model by specifying the path where the model is stored, using the `download_artifact` method:

+MLflow also allows you to perform both operations at once, and to download and load the model in a single instruction. MLflow downloads the model to a temporary folder and loads it from there. The method `load_model` uses an URI format to indicate from where the model has to be retrieved. In the case of loading a model from a run, the URI structure is as follows:

+> To query and load models registered in the model registry, see [Manage models registries in Azure Machine Learning with MLflow](how-to-manage-models-mlflow.md).

+## Get child (nested) runs

+MLflow supports the concept of child (nested) runs. These runs are useful when you need to spin off training routines that must be tracked independently from the main training process. Hyper-parameter tuning optimization processes or Azure Machine Learning pipelines are typical examples of jobs that generate multiple child runs. You can query all the child runs of a specific run using the property tag `mlflow.parentRunId`, which contains the run ID of the parent run.

+ * [Train and track a classifier with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/train-and-log/xgboost_classification_mlflow.ipynb): Demonstrates how to track experiments using MLflow, log models, and combine multiple flavors into pipelines.

+ * [Manage experiments and runs with MLflow](https://github.com/Azure/azureml-examples/blob/main/sdk/python/using-mlflow/runs-management/run_history.ipynb): Demonstrates how to query experiments, runs, metrics, parameters, and artifacts from Azure Machine Learning using MLflow.

+| :-: | :-: | :-: |

+> - ¹ Check the section [Ordering runs](#order-runs) for instructions and examples on how to achieve the same functionality in Azure Machine Learning.

+## Related content

+* [Manage your models with MLflow](how-to-manage-models.md)

+* [Deploy models with MLflow](how-to-deploy-mlflow-models.md)

+In this article, you learn how to train an object detection model to detect small objects in high-resolution images with [automated ML](concept-automated-ml.md) in Azure Machine Learning.

+Typically, computer vision models for object detection work well for datasets with relatively large objects. However, due to memory and computational constraints, these models tend to under-perform when tasked to detect small objects in high-resolution images. Because high-resolution images are typically large, they're resized before input into the model, which limits their capability to detect smaller objects--relative to the initial image size.

+To enable tiling, you can set the `tile_grid_size` parameter to a value like '3x2'; where 3 is the number of tiles along the width dimension and 2 is the number of tiles along the height dimension. When this parameter is set to '3x2'; each image is split into a grid of 3 x 2 tiles. Each tile overlaps with the adjacent tiles, so that any objects that fall on the tile border are included completely in one of the tiles. This overlap is controlled by the `tile_overlap_ratio` parameter, which defaults to 25%.

+For example, when the `tile_grid_size` parameter is '3x2' the computation time would be approximately seven times higher than without tiling.

+Doing so, might improve performance for some datasets, and will not incur the extra cost that comes with tiling at training time.

+> For metrics, the previous example code will only return the last value of a given metric. If you want to retrieve all the values of a given metric, use the `mlflow.get_metric_history` method. For more information on retrieving values of a metric, see [Getting params and metrics from a run](how-to-track-experiments-mlflow.md#get-params-and-metrics-from-a-run).

+# How to use pipeline component to build nested pipeline job (V2)

+# CLI (v2) pipeline component YAML schema

+The YAML syntax detailed in this document is based on the JSON schema for the latest version of the ML CLI v2 extension. This syntax is guaranteed only to work with the latest version of the ML CLI v2 extension. The comprehensive JSON schema can be viewed at [https://azuremlschemas.azureedge.net/latest/monitorSchedule.schema.json](https://azuremlschemas.azureedge.net/latest/monitorSchedule.schema.json).

+| `compute.runtime_version` | String | **Optional**. Defines Spark runtime version. | `3.3` | `3.3` |

+| `production_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `production_data.data_window.lookback_window_offset` and `production_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `production_data.data_window.window_start` and `production_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `production_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `production_data.data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `reference_data.data_column_names.target_column` | Object | **Optional**. If the `reference_data` is training data, this property is required for monitoring top N features for data drift. | | |

+| `reference_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `reference_data.data_window.lookback_window_offset` and `reference_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `reference_data.data_window.window_start` and `reference_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `reference_data_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is **required** if `reference_data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `metric_thresholds.categorical` | Object | Optional. List of metrics and thresholds in 'key:value' format, 'key' is the metric name, 'value' is the threshold. | Allowed categorical metric names: `jensen_shannon_distance`, `chi_squared_test`, `population_stability_index`| |

+| | - | | | - |

+| `type` | String | **Required**. Type of monitoring signal. Prebuilt monitoring signal processing component is automatically loaded according to the `type` specified here. | `prediction_drift` | `prediction_drift` |

+| `production_data.input_data` | Object | **Optional**. Description of input data source, see [job input data](./reference-yaml-job-command.md#job-inputs) specification. | | |

+| `production_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `production_data.data_window.lookback_window_offset` and `production_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `production_data.data_window.window_start` and `production_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `production_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `production_data.data.input_data.type` is `uri_folder`. For more information on preprocessing component specification, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `reference_data` | Object | **Optional**. Recent past production data is used as comparison baseline data if this isn't specified. Recommendation is to use training data as comparison baseline. | | |

+| `reference_data.data_context` | String | The context of data, it refers to the context that dataset was used before | `model_inputs`, `training`, `test`, `validation` | |

+| `reference_data.data_column_names.target_column` | Object | **Optional**. If the 'reference_data' is training data, this property is required for monitoring top N features for data drift. | | |

+| `reference_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `reference_data.data_window.lookback_window_offset` and `reference_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `reference_data.data_window.window_start` and `reference_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `reference_data_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is **required** if `reference_data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `features` | Object | **Optional**. Target features to be monitored for data drift. Some models might have hundreds or thousands of features, it's always recommended to specify interested features for monitoring. | One of following values: list of feature names, `features.top_n_feature_importance`, or `all_features` | Default `features.top_n_feature_importance = 10` if `production_data.data_context` is `training`, otherwise, default is `all_features` |

+| `metric_thresholds.numerical` | Object | Optional. List of metrics and thresholds in 'key:value' format, 'key' is the metric name, 'value' is the threshold. | Allowed numerical metric names: `jensen_shannon_distance`, `normalized_wasserstein_distance`, `population_stability_index`, `two_sample_kolmogorov_smirnov_test`| |

+| `metric_thresholds.categorical` | Object | Optional. List of metrics and thresholds in 'key:value' format, 'key' is the metric name, 'value' is the threshold. | Allowed categorical metric names: `jensen_shannon_distance`, `chi_squared_test`, `population_stability_index`| |

+| `production_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `production_data.data_window.lookback_window_offset` and `production_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `production_data.data_window.window_start` and `production_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `production_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `production_data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `reference_data.data_column_names.target_column` | Object | **Optional**. If the 'reference_data' is training data, this property is required for monitoring top N features for data drift. | | |

+| `reference_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `reference_data.data_window.lookback_window_offset` and `reference_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `reference_data.data_window.window_start` and `reference_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `reference_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `reference_data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `metric_thresholds.categorical` | Object | **Optional** List of metrics and thresholds in `key:value` format, `key` is the metric name, `value` is the threshold. | Allowed categorical metric names: `data_type_error_rate`, `null_value_rate`, `out_of_bounds_rate`| |

+#### Feature attribution drift (preview)

+| `production_data.input_data.data_column_names` | Object | Correlation column name and prediction column names in `key:value` format, needed for data joining. | Allowed keys are: `correlation_id`, `target_column` |

+| `production_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `production_data.data_window.lookback_window_offset` and `production_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `production_data.data_window.window_start` and `production_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `production_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `production_data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `reference_data.data_column_names.target_column` | String | **Required**. | | |

+| `reference_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `reference_data.data_window.lookback_window_offset` and `reference_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `reference_data.data_window.window_start` and `reference_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `reference_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `reference_data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+#### Custom monitoring signal

+Custom monitoring signal through a custom Azure Machine Learning component.

+| Key | Type | Description | Allowed values | Default value |

+| | - | | | - |

+| `type` | String | **Required**. Type of monitoring signal. Prebuilt monitoring signal processing component is automatically loaded according to the `type` specified here. | `custom` | `custom` |

+| `component_id` | String | **Required**. The Azure Machine Learning component ID corresponding to your custom signal. For example `azureml:mycustomcomponent:1` | | |

+| `input_data` | Object | **Optional**. Description of the input data to be analyzed by the monitoring signal, see [job input data](./reference-yaml-job-command.md#job-inputs) specification. | | |

+| `input_data.<data_name>.data_context` | String | The context of data, it refers model production data and could be model inputs or model outputs | `model_inputs` | |

+| `input_data.<data_name>.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `input_data.<data_name>.data_window.lookback_window_offset` and `input_data.<data_name>.data_window.lookback_window_size` properties. For using fixed data windows, please specify `input_data.<data_name>.data_window.window_start` and `input_data.<data_name>.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `input_data.<data_name>.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `input_data.<data_name>.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `alert_enabled` | Boolean | Turn on/off alert notification for the monitoring signal. `True` or `False` | | |

+| `metric_thresholds.metric_name` | Object | Name of the custom metric. | | |

+| `threshold` | Object | Acceptable threshold for the custom metric. | | |

+#### Model performance (preview)

+Model performance tracks the objective performance of a model's output in production by comparing it to collected ground truth data.

+| Key | Type | Description | Allowed values | Default value |

+| | | | --| -|

+| `type` | String | **Required**. Type of monitoring signal. Prebuilt monitoring signal processing component is automatically loaded according to the `type` specified here | `model_performance` | `model_performance` |

+| `production_data` | Array | **Optional**, default to collected data associated with Azure Machine Learning endpoint if this is not provided. The `production_data` is a list of dataset and its associated meta data, it must include both model inputs and model outputs data. It could be a single dataset with both model inputs and outputs, or it could be two separate datasets containing one model inputs and one model outputs.| | |

+| `production_data.input_data` | Object | **Optional**. Description of input data source, see [job input data](./reference-yaml-job-command.md#job-inputs) specification.| | |

+| `production_data.input_data.data_column_names` | Object | Correlation column name and prediction column names in `key:value` format, needed for data joining. | Allowed keys are: `correlation_id`, `target_column` |

+| `production_data.data_context` | String | The context of data. It refers to production model inputs data. | `model_inputs`, `model_outputs`, `model_inputs_outputs` | |

+| `production_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `production_data.data_window.lookback_window_offset` and `production_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `production_data.data_window.window_start` and `production_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `production_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `production_data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `production_data.data_window_size` | String |**Optional**. Data window size in days with ISO8601 format, for example `P7D`. This is the production data window to be computed for data quality issues. | By default the data window size is the last monitoring period.| |

+| `reference_data` | Object | **Optional**. Recent past production data is used as comparison baseline data if this isn't specified. Recommendation is to use training data as comparison baseline. | | |

+| `reference_data.input_data` | Object | Description of input data source, see [job input data](./reference-yaml-job-command.md#job-inputs) specification. | | |

+| `reference_data.data_context` | String | The context of data, it refers to the context that dataset was used before. Fro feature attribution drift, only `training` data allowed. | `training` | |

+| `reference_data.data_column_names.target_column` | String | **Required**. | | |

+| `reference_data.data_window` | Object | **Optional**. Data window of the reference data to be used as comparison baseline data. | Allow either rolling data window or fixed data window only. For using rolling data window, please specify `reference_data.data_window.lookback_window_offset` and `reference_data.data_window.lookback_window_size` properties. For using fixed data windows, please specify `reference_data.data_window.window_start` and `reference_data.data_window.window_end` properties. All property values must be in ISO8601 format. | |

+| `reference_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. This is required if `reference_data.input_data.type` is `uri_folder`, see [preprocessing component specification](./how-to-monitor-model-performance.md#set-up-model-monitoring-by-bringing-in-your-production-data-to-azure-machine-learning). | | |

+| `alert_enabled` | Boolean | Turn on/off alert notification for the monitoring signal. `True` or `False` | | |

+| `metric_thresholds.classification` | Object | **Optional** List of metrics and thresholds in `key:value` format, `key` is the metric name, `value` is the threshold. | Allowed `classification` metric names: `accuracy`, `precision`, `recall`| |

+| `metric_thresholds.regression` | Object | **Optional** List of metrics and thresholds in `key:value` format, `key` is the metric name, `value` is the threshold. | Allowed `regression` metric names: `mae`, `mse`, `rmse`| |

+Monitoring CLI examples are available in the [examples GitHub repository](https://github.com/Azure/azureml-examples/tree/main/cli/monitoring). A couple are as follows:

+## YAML: Out-of-box monitor

+## YAML: Advanced monitor

+| UTC +14:00 | LINE_ISLANDS_STANDARD_TIME | "Line Islands Standard Time" |

+ Title: Monitoring data reference for Azure Notification Hubs

+description: This article contains important reference material you need when you monitor Azure Notification Hubs.

+# Azure Notification Hubs monitoring data reference

+See [Monitor Notification Hubs](monitor-notification-hubs.md) for details on the data you can collect for Azure Notification Hubs and how to use it.

+### Supported metrics for Microsoft.NotificationHubs/namespaces/notificationHubs

+The following table lists the metrics available for the Microsoft.NotificationHubs/namespaces/notificationHubs resource type.

+### Supported resource logs for Microsoft.NotificationHubs/namespaces

+### Supported resource logs for Microsoft.NotificationHubs/namespaces/notificationHubs

+<!-- No table(s) at https://learn.microsoft.com/azure/azure-monitor/reference/tables/tables-resourcetype. -->

+Azure Notification Hubs supports operational logs, which capture management operations that are performed on the Notification Hubs namespace. All logs are stored in JavaScript Object Notation (JSON) format in the following two locations:

+- **AzureActivity**: Displays logs from operations and actions that are conducted against the namespace in the Azure portal or through Azure Resource Manager template deployments.

+- **AzureDiagnostics**: Displays logs from operations and actions that are conducted against the namespace by using the API, or through management clients on the language SDK.

+Diagnostic log JSON strings include the elements listed in the following table:

+| Name | Description |

+| - | - |

+| time | UTC timestamp of the log |

+| resourceId | Relative path to the Azure resource |

+| operationName | Name of the management operation |

+| category | Log category. Valid values: `OperationalLogs` |

+| callerIdentity | Identity of the caller who initiated the management operation |

+| resultType | Status of the management operation. Valid values: `Succeeded` or `Failed` |

+| resultDescription | Description of the management operation |

+| correlationId | Correlation ID of the management operation (if specified) |

+| callerIpAddress | The caller IP address. Empty for calls that originated from the Azure portal |

+Operational logs capture all management operations that are performed on the Azure Notification Hubs namespace. Data operations aren't captured, because of the high volume of data operations that are conducted on notification hubs.

+[Microsoft.NotificationHubs resource provider operations](/azure/role-based-access-control/permissions/integration#microsoftnotificationhubs) lists all the management operations that are captured in operational logs.

+## Related content

+- See [Monitor Notification Hubs](monitor-notification-hubs.md) for a description of monitoring Notification Hubs.

+- See [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for details on monitoring Azure resources.

+ Title: Monitor Azure Notification Hubs

+description: Start here to learn how to monitor Azure Notification Hubs.

+# Monitor Azure Notification Hubs

+<!-- Intro. Required. -->

+For more information about the resource types for Azure Notification Hubs, see [Notification Hubs monitoring data reference](monitor-notification-hubs-reference.md).

+For a list of available metrics for Notification Hubs, see [Notification Hubs monitoring data reference](monitor-notification-hubs-reference.md#metrics).

+### Notification Hubs logs

+Notification Hubs supports activity and operational logs, which capture management operations that are performed on the Notification Hubs namespace. Data operations aren't captured, because of the high volume of data operations that are conducted on notification hubs.

+You can archive the diagnostic logs to a storage account or stream them to an event hub. Sending the logs to a Log Analytics workspace isn't currently supported.

+- For more information about the logs and instructions for enabling log collection, see [Enable diagnostics logs for Notification Hubs](notification-hubs-diagnostic-logs.md).

+- For the available resource log categories, associated Log Analytics tables, and the management operations captured in operational logs, see [Notification Hubs monitoring data reference](monitor-notification-hubs-reference.md#resource-logs).

+## Azure Notification Hubs REST APIs

+The [Notification Hubs REST APIs](/rest/api/notificationhubs) fall into the following categories:

+- **Azure Resource

+- **Notification Hubs service:** APIs that enable operations directly on the Notification Hubs service, and have `<namespaceName>.servicebus.windows.net/` in the request URI.

+The [Get notification message telemetry](/rest/api/notificationhubs/get-notification-message-telemetry) API helps monitor push notifications sent from a hub by providing telemetry on the finished states of outgoing push notifications. The Notification ID that this API uses can be retrieved from the HTTP Location header included in the response of the REST API used to send the notification.

+### Sample Kusto queries

+Failed operations:

+```kusto

+// List all reports of failed operations over the past hour.

+AzureActivity

+| where TimeGenerated > ago(1h)

+| where ActivityStatus == "Failed"

+```

+Errors:

+```kusto

+// List all the errors for the past 7 days.

+AzureDiagnostics

+| where TimeGenerated > ago(7d)

+| where ResourceProvider =="MICROSOFT.NOTIFICATIONHUBS"

+| where Category == "OperationalLogs"

+| summarize count() by "EventName", _ResourceId

+```

+### Notification Hubs alert rules

+The following table lists some suggested alert rules for Notification Hubs. These alerts are just examples. You can set alerts for any metric, log entry, or activity log entry that's listed in the [Notification Hubs monitoring data reference](monitor-notification-hubs-reference.md).

+| Alert type | Condition | Description |

+|:|:|:|

+| Platform metric | Payload Errors | Whenever the count of pushes that failed because the push notification service (PNS) returned a bad payload error is greater than a dynamic threshold |

+| Activity log | Delete Namespace (Namespace) | Whenever the Activity Log has an event with Category='Administrative', Signal name='Delete Namespace (Namespace)' |

+## Related content

+- See [Notification Hubs monitoring data reference](monitor-notification-hubs-reference.md) for a reference of the metrics, logs, and other important values created for Notification Hubs.

+- See [Enable diagnostics logs for Notification Hubs](notification-hubs-diagnostic-logs.md) for information about diagnostic logs for Notification Hubs and how to enable them.

+- See [Get notification message telemetry](/rest/api/notificationhubs/get-notification-message-telemetry) for information about using the API to monitor push notification success.

+- See [Monitoring Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for general details on monitoring Azure resources.

+description: Learn about the operational and diagnostics logs that are available for Azure Notification Hubs, and how to enable diagnostic logging.

+For calls made through Azure Resource Manager the `identity` field contains the username of the logged in user.

+For calls to the Notification Hubs REST API the `identity` field contains the name of the access policy used to generate the SharedAccessSignature token.

+Operational logs capture all management operations that are performed on the Azure Notification Hubs namespace. Data operations aren't captured, because of the high volume of data operations that are conducted on notification hubs.

+For a list of the management operations that are captured in operational logs, see [Microsoft.NotificationHubs resource provider operations](/azure/role-based-access-control/permissions/integration#microsoftnotificationhubs).

+### Enable operational logs

+1. In the **Diagnostics settings** pane, select **Add diagnostic setting**.

+## Related content

+### DNS

+1. Allow the DNS pods to run on the infrastructure nodes.

+ ```

+ oc edit dns.operator/default

+ ```

+ ```

+ apiVersion: operator.openshift.io/v1

+ kind: DNS

+ metadata:

+ name: default

+ spec:

+ nodePlacement:

+ tolerations:

+ - operator: Exists

+ ```

+1. Verify that DNS pods are scheduled onto all infra nodes.

+```

+oc get ds/dns-default -n openshift-dns

+NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE

+dns-default 7 7 7 7 7 kubernetes.io/os=linux 35d

+```

+

+## Logging framework

+> Sections of the following linked content is available only to customers with a current Affirmed Networks support agreement. To access the content, you must have Affirmed Networks login credentials. If you need assistance, please speak to the Affirmed Networks Support Team.

+The logging framework includes the following components:

+The logging framework provides the following features:

+Various dashboards are supported, including:

+The framework aggregates logs from nodes and applications running inside your Azure Operator 5G Core installation. When logging is enabled, the EFK framework uses Fluentd to aggregate event logs from all applications and nodes into Elasticsearch. The EFK framework also provides a centralized Kibana web UI where users can view the logs or create rich visualizations and dashboards with the aggregated data.

+- **AlertManager** - AlertManager handles alerts sent by client applications such as the Prometheus server. It handles deduplicating, grouping, and routing alerts to the correct receiver integrations (email, slack, etc.). AlertManager also supports silencing and inhibition of alerts.

+For more information about Grafana, see [Grafana open source documentation](https://grafana.com/docs/grafana/latest/).

+## Tracing framework

+ Title: Configure the Azure Operator 5G Core extension for status monitoring

+description: Learn how to ensure your deployment is running at its highest capacity by performing health checks post-deployment.

+#CustomerIntent: As a < type of user >, I want < what? > so that < why? >.

+# Configure the Azure Operator 5G Core Preview extension for status monitoring

+After Azure Operator 5G Core Preview is deployed, you can perform health and configuration checks on the deployment. You must enable an ARC extension to monitor your deployment.

+## Set up the Azure CLI

+1. Sign in using the `az login--use-device-code` command. Complete the sign in process with your user account.

+1. Set the subscription: `az account set -s <subscriptionName>`

+1. Run the following commands to install the CLI extensions:

+```azurecli

+ az extension add --yes --name connectedk8s

+ az extension add --yes --name k8s-configuration

+ az extension add --yes --name k8s-extension

+```

+## Configure ARC for the Kubernetes/Azure Kubernetes Services Cluster

+Enter the following command to configure the ARC:

+```azurecli

+az connectedk8s connect --name <ConnectedK8sName> --resource-group <ResourceGroupName>

+```

+## Deploy the Azure Operator 5G Core Preview extension

+1. Enter the following commands to deploy the Azure Operator 5G Core extension:

+ ```azurecli

+ az k8s-extension create \

+ --name ao5gc-monitor \

+ --cluster-name <ConnectedK8sName> \

+ --resource-group <ResourceGroupName> \

+ --cluster-type connectedClusters \

+ --extension-type "Microsoft.AO5GC" \

+ --release-train <dev or preview or stable>\

+ --auto-upgrade true

+ ```

+2. Run the following command to create a **name=ao5gc-monitor** label for the newly created **ao5gc-monitor** namespace:

+ ```azurecli

+ kubectl label namespace ao5gc-monitor name=ao5gc-monitor

+ ```

+ The namespace and all necessary Azure Operator 5G Core extension pods, configuration maps, and services are created within the namespace.

+To delete the Azure Operator 5G Core extension, you can run the following command:

+```azurecli

+az k8s-extension delete \

+--name ao5gc-monitor \

+--cluster-name <ConnectedK8sName> \

+--resource-group <ResourceGroupName> \

+--cluster-type connectedClusters \

+```

+## Related content

+- [Monitor the status of your Azure Operator 5G Core Preview deployment](quickstart-monitor-deployment-status.md)

+- [Observability and analytics in Azure Operator 5G Core Preview](concept-observability-analytics.md)

+[Deployment order for clusters, network functions, and observability.](concept-deployment-order.md)

+ Title: Create dual-stack Azure Operator Nexus Kubernetes cluster

+description: Learn how to create dual-stack Azure Operator Nexus Kubernetes cluster.

+# Create dual-stack Azure Operator Nexus Kubernetes cluster

+In this article, you learn how to create a dual-stack Nexus Kubernetes cluster. The dual-stack networking feature helps to enable both IPv4 and IPv6 communication in a Kubernetes cluster, allowing for greater flexibility and scalability in network communication. The focus of this guide is on the configuration aspects, providing examples to help you understand the process. By following this guide, you're able to effectively create a dual-stack Nexus Kubernetes cluster.

+In a dual-stack Kubernetes cluster, both the nodes and the pods are configured with an IPv4 and IPv6 network address. This means that any pod that runs on a dual-stack cluster will be assigned both IPv4 and IPv6 addresses within the pod, and the cluster nodes' CNI (Container Network Interface) interface will also be assigned both an IPv4 and IPv6 address. However, any multus interfaces attached, such as SRIOV/DPDK, are the responsibility of the application owner and must be configured accordingly.

+<!-- Network Address Translation (NAT) is configured to enable pods to access resources within the local network infrastructure. The source IP address of the traffic from the pods (either IPv4 or IPv6) is translated to the node's primary IP address corresponding to the same IP family (IPv4 to IPv4 and IPv6 to IPv6). This setup ensures seamless connectivity and resource access for the pods within the on-premises environment. -->

+## Prerequisites

+Before proceeding with this how-to guide, it's recommended that you:

+* Refer to the Nexus Kubernetes cluster [QuickStart guide](./quickstarts-kubernetes-cluster-deployment-bicep.md) for a comprehensive overview and steps involved.

+* Ensure that you meet the outlined prerequisites to ensure smooth implementation of the guide.

+* Knowledge of Kubernetes concepts, including deployments and services.

+* The Layer 3 (L3) network used for the `cniNetworkId` must have both IPv4 and IPv6 addresses.

+## Limitations

+* Single stack IPv6-only isn't supported for node or pod IP addresses. Workload Pods and services can use dual-stack (IPv4/IPv6).

+* Kubernetes administration API access to the cluster is IPv4 only. Any kubeconfig must be IPv4 because kube-vip for the kubernetes API server only sets up an IPv4 address.

+* Network Address Translation for IPv6 is disabled by default. If you need NAT for IPv6, you must enable it manually.

+## Configuration options

+Operator Nexus Kubernetes dual-stack networking relies on the pod and service CIDR to enable both IPv4 and IPv6 communication. Before configuring the dual-stack networking, it's important to understand the various configuration options available. These options allow you to define the behavior and parameters of the dual-stack networking according to your specific requirements. Let's explore the configuration options for dual-stack networking.

+### Required parameters

+To configure dual-stack networking in your Operator Nexus Kubernetes cluster, you need to define the `Pod` and `Service` CIDRs. These configurations are essential for defining the IP address range for Pods and Kubernetes services in the cluster.

+* The `podCidrs` parameter takes a list of CIDR notation IP ranges to assign pod IPs from. Example, `["10.244.0.0/16", "fd12:3456:789a::/64"]`.

+* The `serviceCidrs` parameter takes a list of CIDR notation IP ranges to assign service IPs from. Example, `["10.96.0.0/16", "fd12:3456:789a:1::/108"]`.

+* The IPv6 subnet assigned to `serviceCidrs` can be no larger than a `/108`.

+## Bicep template parameters for dual-stack configuration

+The following JSON snippet shows the parameters required for creating dual-stack cluster in the [QuickStart Bicep template](./quickstarts-kubernetes-cluster-deployment-bicep.md).

+```json

+ "podCidrs": {

+ "value": ["10.244.0.0/16", "fd12:3456:789a::/64"]

+ },

+ "serviceCidrs": {

+ "value": ["10.96.0.0/16", "fd12:3456:789a:1::/108"]

+ },

+```

+To create a dual-stack cluster, you need to update the `kubernetes-deploy-parameters.json` file that you created during the [QuickStart](./quickstarts-kubernetes-cluster-deployment-bicep.md). Include the Pod and Service CIDR configuration in this file according to your desired settings, and change the cluster name to ensure that a new cluster is created with the updated configuration.

+After updating the Pod and Service CIDR configuration to your parameter file, you can proceed with deploying the Bicep template. This action sets up your new dual-stack cluster with the specified Pod and Server CIDR configuration.

+By following these instructions, you can create a dual-stack Nexus Kubernetes cluster with the desired IP pool configuration and take advantage of the dual-stack in your cluster services.

+To enable dual-stack `LoadBalancer` services in your cluster, you must ensure that the [IP pools are configured](./howto-kubernetes-service-load-balancer.md) with both IPv4 and IPv6 addresses. This allows the LoadBalancer service to allocate IP addresses from the specified IP pools for the services, enabling effective communication between the services and the external network.

+### Example parameters

+This parameter file is intended to be used with the [QuickStart guide](./quickstarts-kubernetes-cluster-deployment-bicep.md) Bicep template for creating a dual-stack cluster. It contains the necessary configuration settings to set up the dual-stack cluster with BGP load balancer functionality. By using this parameter file with the Bicep template, you can create a dual-stack cluster with the desired BGP load balancer capabilities.

+> [!IMPORTANT]

+> These instructions are for creating a new Operator Nexus Kubernetes cluster. Avoid applying the Bicep template to an existing cluster, as Pod and Service CIDR configurations are immutable.

+```json

+{

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

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "kubernetesClusterName":{

+ "value": "dual-stack-cluster"

+ },

+ "adminGroupObjectIds": {

+ "value": [

+ "00000000-0000-0000-0000-000000000000"

+ ]

+ },

+ "cniNetworkId": {

+ "value": "/subscriptions/<subscription_id>/resourceGroups/<resource_group>/providers/Microsoft.NetworkCloud/l3Networks/<l3Network-name>"

+ },

+ "cloudServicesNetworkId": {

+ "value": "/subscriptions/<subscription_id>/resourceGroups/<resource_group>/providers/Microsoft.NetworkCloud/cloudServicesNetworks/<csn-name>"

+ },

+ "extendedLocation": {

+ "value": "/subscriptions/<subscription_id>/resourceGroups/<managed_resource_group>/providers/microsoft.extendedlocation/customlocations/<custom-location-name>"

+ },

+ "location": {

+ "value": "eastus"

+ },

+ "sshPublicKey": {

+ "value": "ssh-rsa AAAAB...."

+ },

+ "podCidrs": {

+ "value": ["10.244.0.0/16", "fd12:3456:789a::/64"]

+ },

+ "serviceCidrs": {

+ "value": ["10.96.0.0/16", "fd12:3456:789a:1::/108"]

+ },

+ "ipAddressPools": {

+ "value": [

+ {

+ "addresses": ["<IPv4>/<CIDR>", "<IPv6>/<CIDR>"],

+ "name": "<pool-name>",

+ "autoAssign": "True",

+ "onlyUseHostIps": "True"

+ }

+ ]

+ }

+ }

+}

+```

+## Inspect the nodes to see both IP families

+* Once the cluster is provisioned, confirm the nodes are provisioned with dual-stack networking using the `kubectl get nodes` command.

+ ```azurecli

+ kubectl get nodes -o=custom-columns="NAME:.metadata.name,ADDRESSES:.status.addresses[?(@.type=='InternalIP')].address"

+ ```

+The output from the kubectl get nodes command shows the nodes have addresses and pod IP assignment space from both IPv4 and IPv6.

+ ```output

+ NAME ADDRESSES

+ dual-stack-cluster-374cc36c-agentpool1-md-6ff45 10.14.34.20,fda0:d59c:da0a:e22:a8bb:ccff:fe6d:9e2a,fda0:d59c:da0a:e22::11,fe80::a8bb:ccff:fe6d:9e2a

+ dual-stack-cluster-374cc36c-agentpool1-md-dpmqv 10.14.34.22,fda0:d59c:da0a:e22:a8bb:ccff:fe80:f66f,fda0:d59c:da0a:e22::13,fe80::a8bb:ccff:fe80:f66f

+ dual-stack-cluster-374cc36c-agentpool1-md-tcqpf 10.14.34.21,fda0:d59c:da0a:e22:a8bb:ccff:fed5:a3fb,fda0:d59c:da0a:e22::12,fe80::a8bb:ccff:fed5:a3fb

+ dual-stack-cluster-374cc36c-control-plane-gdmz8 10.14.34.19,fda0:d59c:da0a:e22:a8bb:ccff:fea8:5a37,fda0:d59c:da0a:e22::10,fe80::a8bb:ccff:fea8:5a37

+ dual-stack-cluster-374cc36c-control-plane-smrxl 10.14.34.18,fda0:d59c:da0a:e22:a8bb:ccff:fe7b:cfa9,fda0:d59c:da0a:e22::f,fe80::a8bb:ccff:fe7b:cfa9

+ dual-stack-cluster-374cc36c-control-plane-tjfc8 10.14.34.17,10.14.34.14,fda0:d59c:da0a:e22:a8bb:ccff:feaf:21ec,fda0:d59c:da0a:e22::c,fe80::a8bb:ccff:feaf:21ec

+ ```

+## Create an example workload

+Once the cluster has been created, you can deploy your workloads. This article walks you through an example workload deployment of an NGINX web server.

+### Deploy an NGINX web server

+1. Create an NGINX web server using the `kubectl create deployment nginx` command.

+ ```bash-interactive

+ kubectl create deployment nginx --image=mcr.microsoft.com/cbl-mariner/base/nginx:1.22 --replicas=3

+ ```

+2. View the pod resources using the `kubectl get pods` command.

+ ```bash-interactive

+ kubectl get pods -o custom-columns="NAME:.metadata.name,IPs:.status.podIPs[*].ip,NODE:.spec.nodeName,READY:.status.conditions[?(@.type=='Ready')].status"

+ ```

+ The output shows the pods have both IPv4 and IPv6 addresses. The pods don't show IP addresses until they're ready.

+ ```output

+ NAME IPs NODE READY

+ nginx-7d566f5967-gtqm8 10.244.31.200,fd12:3456:789a:0:9ca3:8a54:6c22:1fc8 dual-stack-cluster-374cc36c-agentpool1-md-6ff45 True

+ nginx-7d566f5967-sctn2 10.244.106.73,fd12:3456:789a:0:1195:f83e:f6bd:4809 dual-stack-cluster-374cc36c-agentpool1-md-tcqpf True

+ nginx-7d566f5967-wh2rp 10.244.100.196,fd12:3456:789a:0:c296:3da:b545:aa04 dual-stack-cluster-374cc36c-agentpool1-md-dpmqv True

+ ```

+### Expose the workload via a `LoadBalancer` type service

+1. Expose the NGINX deployment using the `kubectl expose deployment nginx` command.

+ ```bash-interactive

+ kubectl expose deployment nginx --name=nginx --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilyPolicy": "PreferDualStack", "ipFamilies": ["IPv4", "IPv6"]}}'

+ ```

+ You receive an output that shows the services have been exposed.

+ ```output

+ service/nginx exposed

+ ```

+2. Once the deployment is exposed and the `LoadBalancer` services are fully provisioned, get the IP addresses of the services using the `kubectl get services` command.

+ ```bash-interactive

+ kubectl get services

+ ```

+ ```output

+ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

+ nginx LoadBalancer 10.96.119.27 10.14.35.240,fda0:d59c:da0a:e23:ffff:ffff:ffff:fffc 80:30122/TCP 10s

+ ```

+ ```bash-interactive

+ kubectl get services nginx -ojsonpath='{.spec.clusterIPs}'

+ ```

+ ```output

+ ["10.96.119.27","fd12:3456:789a:1::e6bb"]

+ ```

+## Next steps

+You can try deploying a network function (NF) within your Nexus Kubernetes cluster utilizing the dual-stack address.

+If there isn't enough capacity to deploy requested cluster nodes, an error message appears. However, this message doesn't provide any details about the available capacity. It states that the cluster creation can't proceed due to insufficient capacity.

+> [!NOTE]

+> The capacity calculation takes into account the entire platform cluster, rather than being limited to individual racks. Therefore, if an agent pool is created in a zone (where a rack equals a zone) with insufficient capacity, but another zone has enough capacity, the cluster creation continues but will eventually time out. This approach to capacity checking only makes sense if a specific zone isn't specified during the creation of the cluster or agent pool.

+If there isn't enough capacity to deploy requested cluster nodes, an error message appears. However, this message doesn't provide any details about the available capacity. It states that the cluster creation can't proceed due to insufficient capacity.

+> [!NOTE]

+> The capacity calculation takes into account the entire platform cluster, rather than being limited to individual racks. Therefore, if an agent pool is created in a zone (where a rack equals a zone) with insufficient capacity, but another zone has enough capacity, the cluster creation continues but will eventually time out. This approach to capacity checking only makes sense if a specific zone isn't specified during the creation of the cluster or agent pool.

+If there isn't enough capacity to deploy requested cluster nodes, an error message appears. However, this message doesn't provide any details about the available capacity. It states that the cluster creation can't proceed due to insufficient capacity.

+> [!NOTE]

+> The capacity calculation takes into account the entire platform cluster, rather than being limited to individual racks. Therefore, if an agent pool is created in a zone (where a rack equals a zone) with insufficient capacity, but another zone has enough capacity, the cluster creation continues but will eventually time out. This approach to capacity checking only makes sense if a specific zone isn't specified during the creation of the cluster or agent pool.

+If there isn't enough capacity to deploy requested cluster nodes, an error message appears. However, this message doesn't provide any details about the available capacity. It states that the cluster creation can't proceed due to insufficient capacity.

+> [!NOTE]

+> The capacity calculation takes into account the entire platform cluster, rather than being limited to individual racks. Therefore, if an agent pool is created in a zone (where a rack equals a zone) with insufficient capacity, but another zone has enough capacity, the cluster creation continues but will eventually time out. This approach to capacity checking only makes sense if a specific zone isn't specified during the creation of the cluster or agent pool.

+### United States

+### Germany

+|Azure region|

+||

+|Germany West Central (Frankfurt)|

+> Using verify-ca and verify-full **sslmode** configuration settings can also be known as **[certificate pinning](../../security/fundamentals/certificate-pinning.md#how-to-address-certificate-pinning-in-your-application)**. In this case root CA certificates on the PostgreSQL server have to match certificate signature and even host name against certificate on the client. Important to remember, you might periodically need to update client stored certificates when Certificate Authorities change or expire on PostgreSQL server certificates. To determine if you are pinning CAs, please refer to [Certificate pinning and Azure services](../../security/fundamentals/certificate-pinning.md#how-to-address-certificate-pinning-in-your-application).

+> [!NOTE]

+> Azure Database for PostgreSQL - Flexible server doesn't support [certificate based authentication](https://www.postgresql.org/docs/current/auth-cert.html) at this time.

+### Get list of trusted certificates in Java Key Store

+As stated above, Java, by default, stores the trusted certificates in a special file named *cacerts* that is located inside Java installation folder on the client.

+Example below first reads *cacerts* and loads it into *KeyStore* object:

+```java

+private KeyStore loadKeyStore() {

+ String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);

+ String filename = System.getProperty("java.home") + relativeCacertsPath;

+ FileInputStream is = new FileInputStream(filename);

+ KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());

+ String password = "changeit";

+ keystore.load(is, password.toCharArray());

+ return keystore;

+}

+```

+The default password for *cacerts* is *changeit* , but should be different on real client, as administrators recommend changing password immediately after Java installation.

+Once we loaded KeyStore object, we can use the *PKIXParameters* class to read certificates present.

+```java

+public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {

+ KeyStore keyStore = loadKeyStore();

+ PKIXParameters params = new PKIXParameters(keyStore);

+ Set<TrustAnchor> trustAnchors = params.getTrustAnchors();

+ List<Certificate> certificates = trustAnchors.stream()

+ .map(TrustAnchor::getTrustedCert)

+ .collect(Collectors.toList());

+ assertFalse(certificates.isEmpty());

+}

+```

+### Updating Root certificates when using clients in Azure App Services with Azure Database for PostgreSQL - Flexible Server for certificate pinning scenarios

+For Azure App services, connecting to Azure Database for PostgreSQL, we can have two possible scenarios on updating client certificates and it depends on how on you're using SSL with your application deployed to Azure App Services.

+* Usually new certificates are added to App Service at platform level prior to changes in Azure Database for PostgreSQL - Flexible Server. If you are using the SSL certificates included on App Service platform in your application, then no action is needed. Consult following [Azure App Service documentation](../../app-service/configure-ssl-certificate.md) for more information.

+* If you're explicitly including the path to SSL cert file in your code, then you would need to download the new cert and update the code to use the new cert. A good example of this scenario is when you use custom containers in App Service as shared in the [App Service documentation](../../app-service/tutorial-multi-container-app.md#configure-database-variables-in-wordpress)

+ ### Updating Root certificates when using clients in Azure Kubernetes Service (AKS) with Azure Database for PostgreSQL - Flexible Server for certificate pinning scenarios

+If you're trying to connect to the Azure Database for PostgreSQL using applications hosted in Azure Kubernetes Services (AKS) and pinning certificates, it's similar to access from a dedicated customers host environment. Refer to the steps [here](../../aks/ingress-tls.md).

+To disable zone-redundancy for a single database or an elastic pool, you can use the portal or ARM API.

+To disable zone-redundancy for Hyperscale service tier, you can reverse the steps documented in [Redeployment (Hyperscale)](#redeployment-hyperscale).

+# [Elastic pool](#tab/pool)

+1. Go to the [Azure portal](https://portal.azure.com) to find and select the elastic pool that you no longer want to be zone-redundant.

+**To disable zone-redundancy with ARM,** see [Databases - Create Or Update in ARM](/rest/api/sql/elastic-pools/create-or-update?tabs=HTTP) and use the `properties.zoneRedundant` property.

+# [Single database](#tab/single)

+**To disable zone-redundancy with Azure portal:**

+1. Go to the [Azure portal](https://portal.azure.com) to find and select the database that you no longer want to be zone-redundant.

+1. Select **Settings**, and then select **Configure**.

+1. Select **No** for **Would you like to make this database zone redundant?**

+1. Select **Save**.

+

+[Tutorial: Create a highly available multi-region app in Azure App Service](../app-service/tutorial-multi-region-app.md) shows you how to set up an *active-passive* architecture. The same steps with minimal changes (setting priority to ΓÇ£1ΓÇ¥ for both origins in the origin group in Azure Front Door) give you an active-active architecture.

+appliesto:

+- Microsoft Sentinel in the Azure portal

+# Migrate to Microsoft Sentinel with the SIEM migration experience

+- Ingest security data previously used in your source SIEM into Microsoft Sentinel. Install and enable out-of-the-box (OOTB) data connectors to match your security monitoring estate from your source SIEM.

+ - If the data connectors aren't installed yet, find the relevant solutions in **Content hub**.

+Current capabilities:

+- Translated queries feature a completeness status with translation states

+- Support for Splunk macros

+- Support for Splunk lookups

+- Translation of complex correlation logic that queries and correlates events across multiple data sources

+1. Select **SIEM Migration**.

+ - **Translation Type** indicates if a Sentinel OOTB analytics rule matches the Splunk detection logic.

+ - **Translation State** has the following values:

+ - **Fully Translated** queries in this rule were fully translated to KQL

+ - **Partially Translated** queries in this rule weren't fully translated to KQL

+ - **Not Translated** indicates an error in translation

+ - **Manually Translated** when any rule is reviewed and saved

+1. Highlight a rule to resolve translation and select **Edit**. When you are satisfied with the results, select **Save Changes**.

+1. Switch on the **Ready to deploy** toggle for Analytics rules you want to deploy.

+1. Select **Deploy**.

+ | Translation Type | Resource deployed |

+ |:-|:|

+ | Out of the box | The corresponding solutions from **Content hub** that contain the matched analytics rule templates are installed. The matched rules are deployed as active analytics rules in the disabled state. <br><br>For more information, see [Manage Analytics rule templates](manage-analytics-rule-templates.md). |

+ | Custom | Rules are deployed as active analytics rules in the disabled state. |

+1. (Optional) Choose Analytics rules and select **Export Templates** to download them as ARM templates for use in your CI/CD or custom deployment processes.

+ :::image type="content" source="media/siem-migration/export-templates.png" alt-text="Screenshot showing the Review and Migrate tab highlighting the Export Templates button.":::

+1. Before exiting the SIEM Migration experience, select **Download Migration Summary** to keep a summary of the Analytics deployment.

+ :::image type="content" source="media/siem-migration/download-migration-summary.png" alt-text="Screenshot showing the Download Migration Summary button from the Review and Migrate tab.":::

+## Validate and enable rules

+1. Enable rules after you review and verify them.

+ :::image type="content" source="media/siem-migration/enable-deployed-translated-rules.png" alt-text="Screenshot showing Analytics rules with deployed Splunk rules highlighted ready to be enabled.":::

+- [SIEM migration experience now generally available (GA)](#siem-migration-experience-now-generally-available-ga)

+### SIEM migration experience now generally available (GA)

+At the beginning of the month, we announced the SIEM migration preview. Now at the end of the month, it's already GA! The new Microsoft Sentinel Migration experience helps customers and partners automate the process of migrating their security monitoring use cases hosted in non-Microsoft products into Microsoft Sentinel.

+- This first version of the tool supports migrations from Splunk

+For more information, see [Migrate to Microsoft Sentinel with the SIEM migration experience](siem-migration.md)

+Join our Security Community for a [webinar](https://forms.office.com/pages/responsepage.aspx?id=v4j5cvGGr0GRqy180BHbR_0A4IaJRDNBnp8pjCkWnwhUM1dFNFpVQlZJREdEQjkwQzRaV0RZRldEWC4u) showcasing the SIEM migration experience on May 2nd, 2024.

+In this quickstart, you replicated a single VM to a secondary region. Next, [set up replication for multiple Azure VMs](azure-to-azure-tutorial-enable-replication.md).

+- [Review troubleshooting](site-recovery-extension-troubleshoot.md) for the Site Recovery extension on the Azure VM agent.

+- [Quickly replicate](azure-to-azure-quickstart.md) an Azure VM to a secondary region.

+[Replicate Azure VMs to another Azure region](azure-to-azure-how-to-enable-replication.md).

+[Replicate Azure VMs to another Azure region](azure-to-azure-how-to-enable-replication.md).

+## Next steps

+[Replicate Azure VMs to another Azure region](azure-to-azure-how-to-enable-replication.md).

+In this tutorial, you ran a disaster recovery drill to check that failover works as expected. Now you can try to [run a production failover](azure-to-azure-tutorial-failover-failback.md).

+Now, try out disaster recovery to Azure for an [on-premises VM](vmware-azure-tutorial-prepare-on-premises.md).

+In this tutorial, you failed over from the primary region to the secondary, and started replicating VMs back to the primary region. Now you can [fail back from the secondary region to the primary](azure-to-azure-tutorial-failback.md).

+- For High churn VMs, more data changes may get replicated to target for **High churn** compared to **Normal churn**. This may lead to more network cost.

+## Next steps

+[Set up disaster recovery for Azure VMs](azure-to-azure-tutorial-enable-replication.md).

+## Next steps

+Learn more about:

+- [Get-AzRecoveryServicesVault](/powershell/module/az.recoveryservices/get-azrecoveryservicesvault)

+- [Remove-AzRecoveryServicesVault](/powershell/module/az.recoveryservices/remove-azrecoveryservicesvault).

+ Title: Monitoring data reference for Azure Site Recovery

+description: This article contains important reference material you need when you monitor Azure Site Recovery.

+# Azure Site Recovery monitoring data reference

+See [Monitor Azure Site Recovery](monitor-site-recovery.md) for details on the data you can collect for Azure Site Recovery and how to use it.

+## Metrics

+There are no automatically collected metrics for Azure Site Recovery. All the automatically collected metrics for the `Microsoft.RecoveryServices/Vaults` namespace are for the Azure Backup service. For information about Azure Backup metrics, see [Monitor Azure Backup](/azure/backup/backup-azure-monitoring-built-in-monitor).

+### Supported resource logs for Microsoft.RecoveryServices/Vaults

+Note that some of the following logs apply to Azure Backup and others apply to Azure Site Recovery, as noted in the **Category display name** column.

+### Recovery Services Vaults

+Microsoft.RecoveryServices/Vaults

+- [AzureActivity](/azure/azure-monitor/reference/tables/AzureActivity#columns)

+- [ASRJobs](/azure/azure-monitor/reference/tables/ASRJobs#columns)

+- [ASRReplicatedItems](/azure/azure-monitor/reference/tables/ASRReplicatedItems#columns)

+- [AzureDiagnostics](/azure/azure-monitor/reference/tables/AzureDiagnostics#columns)

+- [Microsoft.RecoveryServices](/azure/role-based-access-control/permissions/management-and-governance#microsoftrecoveryservices)

+## Related content

+- See [Monitor Site Recovery](monitor-site-recovery.md) for a description of monitoring Site Recovery.

+- See [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for details on monitoring Azure resources.

+ Title: Monitor Azure Site Recovery

+description: Start here to learn how to monitor Azure Site Recovery.

+# Monitor Azure Site Recovery

+## Built-in monitoring for Azure Site Recovery

+An Azure Recovery Services vault supports both Azure Site Recovery and Azure Backup services and features. In the Azure portal, the **Site Recovery** tab of the Recovery Services vault **Overview** page provides a dashboard that shows the following monitoring information:

+- Replication health

+- Failover health

+- Configuration issues

+- Recovery plans

+- Errors

+- Jobs

+- Infrastructure view of machines replicating to Azure

+For a detailed description of how to monitor Azure Site Recovery in the Azure portal by using the Recovery Services dashboard, see [Monitor in the dashboard](site-recovery-monitor-and-troubleshoot.md#monitor-in-the-dashboard).

+Azure Backup Center also provides at-scale monitoring and management capabilities for Azure Site Recovery. For more information, see [About Backup center for Azure Backup and Azure Site Recovery](/azure/backup/backup-center-overview).

+### Monitor churn rate

+High data change rates (churn) are a common source of replication issues. You can use various tools, including Azure Monitor Logs, to monitor churn patterns on virtual machines. For more information, see [Monitor churn patterns on virtual machines](monitoring-high-churn.md).

+Azure Site Recovery shares the `Microsoft.RecoveryServices/Vaults` namespace with Azure Backup. For more information, see [Azure Site Recovery monitoring data reference](monitor-site-recovery-reference.md).

+There are no automatically collected platform metrics for Azure Site Recovery. All the automatically collected metrics for the `Microsoft.RecoveryServices/Vaults` namespace pertain to the Azure Backup service. For information about Azure Backup metrics, see [Monitor the health of your backups using Azure Backup Metrics (preview)](/azure/backup/metrics-overview).

+### Azure Site Recovery resource logs

+Using Azure Monitor Logs with Azure Site Recovery is supported for **Azure to Azure** replication and **VMware VM/physical server to Azure** replication.

+You can use Azure Monitor Logs to monitor:

+- Replication health

+- Test failover status

+- Site Recovery events

+- Recovery point objectives (RPOs) for protected machines

+- Disk/data change rates (churn)

+For detailed instructions on using diagnostic settings to collect and route Site Recovery logs and events, see [Monitor Site Recovery with Azure Monitor Logs](monitor-log-analytics.md).

+To get churn data and upload rate logs for VMware and physical machines, you need to install a Microsoft monitoring agent on the process server. This agent sends the logs of the replicating machines to the workspace.

+For instructions, see [Configure Microsoft monitoring agent on the process server to send churn and upload rate logs](monitor-log-analytics.md#configure-microsoft-monitoring-agent-on-the-process-server-to-send-churn-and-upload-rate-logs). For more information about monitoring the process server and the health alerts it generates, see [Monitor the process server](vmware-physical-azure-monitor-process-server.md).

+- For more information about the resource logs collected for Site Recovery, see [Common questions about Azure Site Recovery monitoring](monitoring-common-questions.md#azure-monitor-logging).

+- For the available resource log categories, associated Log Analytics tables, and logs schemas for Azure Site Recovery, see [Site Recovery monitoring data reference](monitor-site-recovery-reference.md#resource-logs).

+### Example queries

+For example Kusto queries you can use for Site Recovery monitoring, see [Query the logs - examples](monitor-log-analytics.md#query-the-logsexamples).

+You can set up alerts for any log entry listed in the [Azure Site Recovery monitoring data reference](monitor-site-recovery-reference.md). For example, you can configure alerts for machine health, test failover status, or Site Recovery job status.

+For detailed query examples and scenarios you can use for setting up Site Recovery alerts, see [Set up alerts - examples](monitor-log-analytics.md#set-up-alertsexamples).

+### Built-in Azure Monitor alerts for Azure Site Recovery

+Azure Site Recovery provides default alerts via Azure Monitor as a preview feature. Once you register this feature, Azure Site Recovery surfaces a default alert via Azure Monitor whenever any of the following critical events occur:

+- Enable disaster recovery failure alerts for Azure VM, Hyper-V, and VMware replication.

+- Replication health critical alerts for Azure VM, Hyper-V, and VMware replication.

+- Azure Site Recovery agent version expiry alerts for Azure VM and Hyper-V replication.

+- Azure Site Recovery agent not reachable alerts for Hyper-V replication.

+- Failover failure alerts for Azure VM, Hyper-V, and VMware replication.

+- Auto certification expiry alerts for Azure VM replication.

+For detailed instructions on enabling and configuring these built-in alerts, see [Built-in Azure Monitor alerts for Azure Site Recovery (preview)](site-recovery-monitor-and-troubleshoot.md#built-in-azure-monitor-alerts-for-azure-site-recovery-preview). Also see [Common questions about built-in Azure Monitor alerts for Azure Site Recovery](monitoring-common-questions.md#built-in-azure-monitor-alerts-for-azure-site-recovery).

+## Related content

+- See [Site Recovery monitoring data reference](monitor-site-recovery-reference.md) for a reference of the metrics, logs, and other important values created for Site Recovery.

+- See [Monitoring Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for general details on monitoring Azure resources.

+ Title: Azure Site Recovery dashboard and built-in alerts

+description: Monitor and troubleshoot Azure Site Recovery replication issues and operations, and enable built-in alerts, by using the portal.

+| Property | Required? | Description |

+||--|-|

+| `Name` | Yes | A unique name to label each Git repository. |

+| `Patterns` | Yes | The patterns to search for in Git repositories. For each pattern, use a format such as *{application}* or *{application}/{profile}* rather than *{application}-{profile}.yml*. Separate the patterns with commas. For more information, see the [Pattern](#pattern) section of this article. |

+| `URI` | Yes | A Git URI (for example, `https://github.com/Azure-Samples/piggymetrics-config` or `git@github.com:Azure-Samples/piggymetrics-config`) |

+| `Label` | Yes | The branch name to search for in the Git repository. |

+| `Search path` | No | Optional search paths, separated by commas, for searching subdirectories of the Git repository. |

+- `ConfigMap` update and interaction with kubelet cache: In Azure Spring Apps, this `ConfigMap` is mounted as a data volume to the relevant application. However, there's a natural delay in this process due to the frequency at which the kubelet refreshes its cache to recognize changes in `ConfigMap`.

+## Examine configuration file in ConfigMap

+The following section shows you how to examine the content of the configuration file pulled by Application Configuration Service from upstream Git repositories in the related Kubernetes `ConfigMap`. For more information, see the [Refresh strategies](#refresh-strategies) section of this article.

+### Assign an Azure role

+First, you must have the Azure role `Azure Spring Apps Application Configuration Service Config File Pattern Reader Role` assigned to you.

+#### [Azure portal](#tab/azure-Portal)

+Use the following steps to assign an Azure role:

+1. Open the [Azure portal](https://portal.azure.com) and go to your Azure Spring Apps service instance.

+1. In the navigation pane, select **Access Control (IAM)**.

+1. On the **Access Control (IAM)** page, select **Add**, and then select **Add role assignment**.

+ :::image type="content" source="media/how-to-enterprise-application-configuration-service/add-role-assignment.png" alt-text="Screenshot of the Azure portal that shows the Access Control (IAM) page for an Azure Spring Apps instance with the Add role assignment option highlighted." lightbox="media/how-to-enterprise-application-configuration-service/add-role-assignment.png":::

+1. On the **Add role assignment** page, in the **Name** list, search for and select the target role, and then select **Next**.

+ :::image type="content" source="media/how-to-enterprise-application-configuration-service\application-configuration-service-config-pattern-file-reader-role.png" alt-text="Screenshot of the Azure portal that shows the Add role assignment page for an Azure Spring Apps instance with the Azure Spring Apps Application Configuration Service Config File Pattern Reader Role name highlighted." lightbox="media/how-to-enterprise-application-configuration-service\application-configuration-service-config-pattern-file-reader-role.png":::

+1. Select **Members** and then search for and select your username.

+1. Select **Review + assign**.

+#### [Azure CLI](#tab/azure-CLI)

+Use the following command to assign an Azure role:

+```azurecli

+az role assignment create \

+ --role "Azure Spring Apps Application Configuration Service Config File Pattern Reader Role" \

+ --scope "<service-instance-resource-id>" \

+ --assignee "<your-identity>"

+```

+### Examine configuration file with Azure CLI

+Use the following command to view the content of the configuration file by [Pattern](#pattern):

+```azurecli

+az spring application-configuration-service config show \

+ --resource-group <resource-group-name> \

+ --service <Azure-Spring-Apps-instance-name> \

+ --config-file-pattern <pattern>

+```

+This command produces JSON output similar to the following example:

+```json

+{

+ "configurationFiles": {

+ "application.properties": [

+ "example.property.application.name: example-service",

+ "example.property.cloud: Azure"

+ ]

+ }

+}

+```

+You can also use this command with the `--export-path {/path/to/target/folder}` parameter to export the configuration file to the specified folder. It supports both relative paths and absolute paths. If you don't specify the path, the command uses the path of the current directory by default.

+## Examine configuration file in the app

+After you bind the app to the Application Configuration Service and set the [Pattern](#pattern) for the app deployment, as described in the [Use Application Configuration Service with applications](#use-application-configuration-service-with-applications) section of this article, the `ConfigMap` containing the configuration file for the pattern should be mounted to the application container. Use the following steps to check the configuration files in each instance of the app deployment:

+1. Connect to one of the application instances. For more information, see [Connect to an app instance for troubleshooting](./how-to-connect-to-app-instance-for-troubleshooting.md).

+1. Use the `echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH` command to find the folders containing the configuration files. A list of locations shows up separated by commas, as shown in the following example:

+ ```output

+ $ echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH

+ /etc/azure-spring-cloud/configmap/acs-default-payment-default-e9d46,/etc/azure-spring-cloud/configmap/acs-default-catalog-default-616f4

+ ```

+1. Check the content of the configuration file using commands such as `cat`.

+- Confirm that the `ConfigMap` containing the configuration file for the [Pattern](#pattern) used by the application is updated, as described in the [Examine configuration file in ConfigMap](#examine-configuration-file-in-configmap) section of this article. If it isn't updated, raise a ticket.

+- Confirm that the `ConfigMap` is mounted to the application as a file, as described in the [Examine configuration file in the app](#examine-configuration-file-in-the-app) section of this article. If the file isn't updated, wait for the Kubernetes refresh interval (1 minute), or force a refresh by restarting the application.

+Azure Event Grid raises **Microsoft.Storage.BlobTierChanged** event on the completion of blob rehydration:

+- The **Microsoft.Storage.BlobTierChanged** event fires when a blob's tier is changed. In the context of blob rehydration, this event fires when the access tier of a destination blob is successfully changed from archive tier to an online tier (hot, cool or cold tier). You can use Set Blob Tier operation to change the access tier of an archived blob or use Copy Blob operation to copy an archived blob to a new destination blob in an online tier.

+<!-- replaycheck-task id="cb105ef6" -->

+<!-- replaycheck-task id="e3ce9356" -->

+<!-- replaycheck-task id="2de8753c" -->

+<!-- replaycheck-task id="542306be" -->

+<!-- replaycheck-task id="57011072" -->

+<!-- replaycheck-task id="c0f2f9d5" -->

+<!-- replaycheck-task id="fee1778" -->

+<!-- replaycheck-task id="3361d580" -->

+<!-- replaycheck-task id="60f1639b" -->

+<!-- replaycheck-task id="8cdad632" -->

+### Reports might exclude soft-deleted blobs in accounts that have a hierarchical namespace

+If a container or directory is deleted with soft-delete enabled, then the container or directory and all its contents are marked as soft-deleted. However, only the container or directory (reported as a zero-length blob) appears in an inventory report and not the soft-deleted blobs in that container or directory even if you set the `includeDeleted` field of the policy to **true**. This can lead to a difference between what appears in capacity metrics that you obtain in the Azure Portal and what is reported by an inventory report.

+Only blobs that are explicitly deleted appear in reports. Therefore, to obtain a complete listing of all soft-deleted blobs (directory and all child blobs), workloads should delete each blob in a directory before deleting the directory itself.

+- Azure File Sync doesn't support customer initiated storage account failover. Storage accounts containing Azure file shares being used as cloud endpoints in Azure File Sync shouldn't be failed over. Doing so will cause sync to stop working and may also cause unexpected data loss in the case of newly tiered files. For more information, see [Best practices for disaster recovery with Azure File Sync](../file-sync/file-sync-disaster-recovery-best-practices.md#geo-redundancy) for details.

+#### Azure Files geo-redundancy for standard large file shares is generally available

+Standard SMB file shares that are geo-redundant (GRS and GZRS) can now scale up to 100TiB capacity with significantly improved IOPS and throughput limits. For more information, see [blog post](https://techcommunity.microsoft.com/t5/azure-storage-blog/general-availability-azure-files-geo-redundancy-for-standard/ba-p/4097935) and [documentation](geo-redundant-storage-for-large-file-shares.md).

+| China East | GA |

+| China North | GA |

+| US Gov Arizona | GA |

+| US Gov Texas | GA |

+| US Gov Virginia | GA |

+1. Specify the **Serialization** type of your data in the Event Hubs and the **Authentication method** that the job uses to connect to Event Hubs. Then select **Connect**.

+1. When the connection is established successfully, you see:

+ 1. Select the subscription, storage account name, and container from the drop-down menu.

+ 1. For **Delta table path**, it's used to specify the location and name of your Delta Lake table stored in Azure Data Lake Storage Gen2. You can choose to use one or more path segments to define the path to the delta table and the delta table name. To learn more, see to [Write to Delta Lake table](./write-to-delta-lake.md).

+1. When the connection is established, you see fields that are present in the output data.

+1. After you select **Start**, the job starts running within two minutes, and the metrics will be open in tab section as shown in the following image.

+ Title: Build real-time dashboard with Azure Stream Analytics no-code editor, Synapse Analytics, and Power BI

+description: Use no code editor to compute aggregations and write to Azure Synapse Analytics and build real-time dashboards using Power BI.

+4. [Create a table](../synapse-analytics/sql/get-started-visual-studio.md) named `carsummary` using your Dedicated SQL pool. You can do it by running the following SQL script:

+ Make nvarchar(20),

+ CarCount int,

+ times datetime

+ )

+ 1. For **Consumer group**, select **Use existing**, and then select **Default**.

+ 1. For **Serialization type**, confirm that **JSON** is selected.

+ 1. For **Authentication mode**, confirm that **Connection String** is used to connect to your event hub: Connection string.

+1. Within few seconds, you see sample input data and the schema. You can choose to drop fields, rename fields or change data type if you want.

+1. Select **Operations** on the command bar and then select **Group by**.

+ :::image type="content" source="./media/stream-analytics-no-code/select-operations-group-by.png" alt-text="Screenshot showing the Operations menu with Group by selected on the command bar.":::

+ 1. Select **Add**.

+ :::image type="content" source="./media/stream-analytics-no-code/group-by-aggregations.png" alt-text="Screenshot of the Aggregations setting in the Group by configuration page." :::

+ 1. In the **Settings** section:

+ 1. For **Group aggregations by**, select **Make**.

+ 1. For **Time window**, confirm that the value is set to **Tumbling**.

+ 1. For **Duration**, enter **3 minutes**

+ 1. Select **Done** at the bottom of the page.

+ :::image type="content" source="./media/stream-analytics-no-code/group-settings.png" alt-text="Screenshot of the Group by configuration page." lightbox="./media/stream-analytics-no-code/group-settings.png":::

+1. Select **Group by**, and notice the grouped data in the **Data preview** tab at the bottom of the page.

+ :::image type="content" source="./media/stream-analytics-no-code/group-by-data-preview.png" alt-text="Screenshot that shows the Data Preview tab for the Group by operation." lightbox="./media/stream-analytics-no-code/group-by-data-preview.png":::

+1. On the command bar, select **Operations** and then **Manage fields**.

+1. Connect **Group by** and **Manage fields** tiles.

+1. On the **Manage fields** page, follow these steps:

+ 1. Add the **Make** field as shown in the following image, and then select **Add**.

+ :::image type="content" source="./media/stream-analytics-no-code/add-make-field.png" alt-text="Screenshot showing the addition of the Make field." lightbox="./media/stream-analytics-no-code/add-make-field.png":::

+ 2. Select **Add** button.

+

+ :::image type="content" source="./media/stream-analytics-no-code/add-make-field-button.png" alt-text="Screenshot showing the Add button on the Manage fields page.":::

+1. Select **Add all fields** on the **Manage fields** configuration page.

+1. Select **Done** on the **Manage fields** page. The **Manage fields** page should look as shown in the following image.

+1. Select **Manage fields** tile, and see the data flowing into the operation in the **Data preview** tab at the bottom of the page.

+ :::image type="content" source="./media/stream-analytics-no-code/manage-fields-data-preview.png" alt-text="Screenshot that shows the Data Preview tab for the Managed Fields operation." lightbox="./media/stream-analytics-no-code/manage-fields-data-preview.png":::

+1. On the command bar, select **Outputs**, and then select **Synapse**.

+ :::image type="content" source="./media/stream-analytics-no-code/select-output-synapse.png" alt-text="Screenshot of command bar with Outputs, Synapse selected.":::

+1. Connect the **Synapse** tile to the **Manage fields** tile on your canvas.

+1. On the **Synapse** settings page, follow these steps:

+ 1. If the **Job storage account** isn't already set, select the Azure Data Lake Storage account in the resource group. It's the storage account that is used by Synapse SQL to load data into your data warehouse.

+

+ :::image type="content" source="./media/stream-analytics-no-code/select-synapse-storage-account.png" alt-text="Screenshot that shows the Synapse with selection of storage account.":::

+ 1. Select the Azure subscription where your Azure Synapse Analytics is located.

+ 1. Select the database of the Dedicated SQL pool that you used to create the `carsummary` table in the previous section.

+ 1. Enter username and password to authenticate.

+ 1. Enter table name as `carsummary`.

+ 1. Select **Connect**. You see sample results that will be written to your Synapse SQL table.

+1. Select **Synapse** tile and see the **Data preview** tab at the bottom of the page. You see the data flowing into the dedicated SQL pool.

+ :::image type="content" source="./media/stream-analytics-no-code/synapse-data-preview.png" alt-text="Screenshot that shows Data Preview for the Synapse tile." lightbox="./media/stream-analytics-no-code/synapse-data-preview.png":::

+1. Select **Save** in the top ribbon to save your job and then select **Start**.

+ :::image type="content" source="./media/stream-analytics-no-code/start-job-button.png" alt-text="Screenshot that shows the Start button selected on the command bar." lightbox="./media/stream-analytics-no-code/start-job-button.png":::

+1. On the **Start Stream Analytics Job** page, select **Start** to run your job.

+1. You then see a list of all Stream Analytics jobs created using the no code editor. And within two minutes, your job goes to a **Running** state. Select the **Refresh** button on the page to see the status changing from Created -> Starting -> Running.

+2. Use the Power BI connector for Azure Synapse SQL.

+ :::image type="content" source="./media/stream-analytics-no-code/power-bi-get-data-azure-synapse.png" alt-text="Screenshot that shows the Power BI Desktop with Azure and Synapse Analytics SQL selected." lightbox="./media/stream-analytics-no-code/power-bi-get-data-azure-synapse.png":::

+1. Connect to your database with **DirectQuery**, and use this query to fetch data from your database

+ :::image type="content" source="./media/stream-analytics-no-code/power-bi-direct-query.png" alt-text="Screenshot that shows the configuration of Power BI Destop to connect to Azure Synapse SQL Database." lightbox="./media/stream-analytics-no-code/power-bi-direct-query.png":::

+ Switch to **Database** tab, and enter your credentials (user name and password) to connect to the database and run the query.

+1. Select **Load** to load data into the Power BI.

+1. You can then create a line chart with

+1. **Through Azure Stream Analytics portal (preview)**: Create a Stream Analytics job, and then select the no-code editor in the **Get started** tab in **Overview** page, or select **No-code editor** in the left panel.

+ :::image type="content" source="./media/no-code-stream-processing/no-code-on-asa-portal.png" alt-text="Screenshot that shows no-code on Azure Stream Analytics portal locations." lightbox="./media/no-code-stream-processing/no-code-on-asa-portal.png" :::

+2. **Through Azure Event Hubs portal**: Open an Event Hubs instance. Select **Process Data**, and then select any predefined template.

+ The predefined templates can assist you in developing and running a job to address various scenarios, including:

+The following screenshot shows a completed Stream Analytics job. It highlights all the sections available to you as you author.

+1. **Ribbon**: On the ribbon, sections follow the order of a classic analytics process: an event hub as input (also known as a data source), transformations (streaming Etract, Transform, and Load operations), outputs, a button to save your progress, and a button to start the job.

+3. **Side pane**: Depending on which component you selected in the diagram view, you see settings to modify input, transformation, or output.

+4. **Tabs for data preview, authoring errors, runtime logs, and metrics**: For each tile, the data preview shows you results for that step (live for inputs; on demand for transformations and outputs). This section also summarizes any authoring errors or warnings that you might have in your job when it's being developed. Selecting each error or warning selects that transform. It also provides the job metrics for you to monitor the running job's health.

+When you're connecting to the event hub, if you select **Managed Identity** as the authentication mode, the Azure Event Hubs Data Owner role is granted to the managed identity for the Stream Analytics job. To learn more about managed identities for an event hub, see [Use managed identities to access an event hub from an Azure Stream Analytics job](event-hubs-managed-identity.md).

+When Stream Analytics jobs detect the fields, you see them in the list. You also see a live preview of the incoming messages in the **Data Preview** table under the diagram view.

+> This applies to the input data from Azure IoT Hub and Azure Data Lake Storage Gen2 as well.

+**Write to Delta Lake table (preview)** is supported in the ADLS Gen2 as no code editor output. You can access this option in section **Serialization** in ADLS Gen2 configuration. For more information about this feature, see [Write to Delta Lake table](./write-to-delta-lake.md).

+### Event Hubs

+With the real-time data coming through to ASA, no-code editor can transform, enrich the data and then output the data to another event hub as well. You can choose the **Event Hubs** output when you configure your Azure Stream Analytics job.

+description: This article describes how to use Azure Stream Analytics to save output to Azure Cosmos DB for JSON output.

+Azure Stream Analytics can output data in JSON format to [Azure Cosmos DB](https://azure.microsoft.com/services/documentdb/). It enables data archiving and low-latency queries on unstructured JSON data. This article covers some best practices for implementing this configuration (Stream Analytics to Cosmos DB). If you're unfamiliar with Azure Cosmos DB, see the [Azure Cosmos DB documentation](../cosmos-db/index.yml) to get started.

+> - At this time, Stream Analytics supports connection to Azure Cosmos DB only through the *SQL API*.Other Azure Cosmos DB APIs are not yet supported. If you point Stream Analytics to Azure Cosmos DB accounts created with other APIs, the data might not be properly stored.

+> - We recommend that you set your job to compatability level 1.2 when using Azure Cosmos DB as output.

+The Azure Cosmos DB output in Stream Analytics enables writing your stream processing results as JSON output into your Azure Cosmos DB containers. Stream Analytics doesn't create containers in your database. Instead, it requires you to create them beforehand. You can then control the billing costs of Azure Cosmos DB containers. You can also tune the performance, consistency, and capacity of your containers directly by using the [Azure Cosmos DB APIs](/rest/api/cosmos-db/). The following sections detail some of the container options for Azure Cosmos DB.

+Depending on what levels of read consistency your scenario needs against read and write latency, you can choose a consistency level on your database account. You can improve throughput by scaling up Request Units (RUs) on the container. Also by default, Azure Cosmos DB enables synchronous indexing on each CRUD operation to your container. This option is another useful one to control write/read performance in Azure Cosmos DB. For more information, review the [Change your database and query consistency levels](../cosmos-db/consistency-levels.md) article.

+Stream Analytics integration with Azure Cosmos DB allows you to insert or update records in your container based on a given **Document ID** column. This operation is also called an *upsert*. Stream Analytics uses an optimistic upsert approach. Updates happen only when an insert fails with a document ID conflict.

+Azure Cosmos DB automatically scales partitions based on your workload. So we recommend that you use [unlimited](../cosmos-db/partitioning-overview.md) containers for partitioning your data. When Stream Analytics writes to unlimited containers, it uses as many parallel writers as the previous query step or input partitioning scheme.

+It's important to choose a partition key property that has many distinct values, and that lets you distribute your workload evenly across these values. As a natural artifact of partitioning, requests that involve the same partition key are limited by the maximum throughput of a single partition.

+The storage size for documents that belong to the same partition key value is limited to 20 GB (the [physical partition size limit](../cosmos-db/partitioning-overview.md) is 50 GB). An [ideal partition key](../cosmos-db/partitioning-overview.md#choose-partitionkey) is the one that appears frequently as a filter in your queries and has sufficient cardinality to ensure that your solution is scalable.

+Partition keys used for Stream Analytics queries and Azure Cosmos DB don't need to be identical. Fully parallel topologies recommend using *Input Partition key*, `PartitionId`, as the Stream Analytics query's partition key but that might not be the recommended choice for an Azure Cosmos DB container's partition key.

+With levels before 1.2, Stream Analytics uses a custom stored procedure to bulk upsert documents per partition key into Azure Cosmos DB. There, a batch is written as a transaction. Even when a single record hits a transient error (throttling), the whole batch has to be retried. This behavior makes scenarios with even reasonable throttling relatively slow.

+The incoming event rate in Event Hubs is two times higher than Azure Cosmos DB containers (20,000 RUs) are configured to take in, so throttling is expected in Azure Cosmos DB. However, the job with 1.2 is consistently writing at a higher throughput (output events per minute) and with a lower average SU% utilization. In your environment, this difference depends on few more factors. These factors include choice of event format, input event/message size, partition keys, and query.

+With 1.2, Stream Analytics is more intelligent in utilizing 100 percent of the available throughput in Azure Cosmos DB with few resubmissions from throttling or rate limiting. This behavior provides a better experience for other workloads like queries running on the container at the same time. If you want to see how Stream Analytics scales out with Azure Cosmos DB as a sink for 1,000 to 10,000 messages per second, try [this Azure sample project](https://github.com/Azure-Samples/streaming-at-scale/tree/main/eventhubs-streamanalytics-cosmosdb).

+|Document ID | Optional. The column name in output events used as the unique key on which insert or update operations must be based. If you leave it empty, all events are inserted, with no update option.|

+2. The `PartitionKey` column doesn't exists.

+3. The `Id` column doesn't exist.

+In this tutorial, you create an Azure Stream Analytics job that reads events from Azure Event Hubs, runs a query on the event data, and then invokes an Azure function, which writes to an Azure Cache for Redis instance.

+> - You can run Azure Functions from Azure Stream Analytics by configuring Functions as one of the sinks (outputs) to the Stream Analytics job. Functions are an event-driven, compute-on-demand experience that lets you implement code that is triggered by events occurring in Azure or third-party services. This ability of Functions to respond to triggers makes it a natural output to Stream Analytics jobs.

+> - Stream Analytics invokes Functions through HTTP triggers. The Functions output adapter allows users to connect Functions to Stream Analytics, such that the events can be triggered based on Stream Analytics queries.

+> - Connection to Azure Functions inside a virtual network (VNet) from an Stream Analytics job that is running in a multi-tenant cluster is not supported.

+> * Create an Azure Event Hubs instance

+> * Create a Stream Analytics job

+> * Configure event hub as input and function as output

+> * Run the Stream Analytics job

+ > The following sample script assumes that you used **CallStream** for input name and **saop1** for the output name. If you used different names, DON'T forget to update the query.

+Retrying for timeouts might result in duplicate events written to the output sink. When Stream Analytics retries for a failed batch, it retries for all the events in the batch. For example, consider a batch of 20 events that are sent to Azure Functions from Stream Analytics. Assume that Azure Functions takes 100 seconds to process the first 10 events in that batch. After 100 seconds, Stream Analytics suspends the request since it hasn't received a positive response from Azure Functions, and another request is sent for the same batch. The first 10 events in the batch are processed again by Azure Functions, which causes a duplicate.

+ Title: Azure Stream Analytics - Writing to Delta Lake table

+Delta Lake is an open format that brings reliability, quality, and performance to data lakes. Azure Stream Analytics allows you to directly write streaming data to your delta lake tables without writing a single line of code.

+A stream analytics job can be configured to write through a native delta lake output connector, either to a new or a precreated Delta table in an Azure Data Lake Storage Gen2 account. This connector is optimized for high-speed ingestion to delta tables in append mode and also provides exactly once semantics, which guarantees that no data is lost or duplicated. Ingesting real-time data streams from Azure Event Hubs into Delta tables allows you to perform ad-hoc interactive or batch analytics.

+|Event Serialization Format|Serialization format for output data. JSON, CSV, AVRO, Parquet are supported. Delta Lake is listed as an option here. The data is in Parquet format if Delta Lake is selected. |

+|Delta path name| The path that is used to write your delta lake table within the specified container. It includes the table name. More details in the next section. |

+The segment name is alphanumeric and can include spaces, hyphens, and underscores. The last path segment is used as the table name.

+- Field names aren't case-sensitive. For example, the service can't differentiate between column `ID` and `id`.

+- No dynamic {field} name is allowed. For example, {ID} is treated as text {ID}.

+1. Under the chosen container, directory path would be `WestEurope/CA/factory1` and delta table folder name would be **device-table**.

+2. Under the chosen container, directory path would be `Test` and delta table folder name would be **demo**.

+If there isn't already a Delta Lake table with the same name and in the location specified by the Delta Path name, by default, Azure Stream Analytics creates a new Delta Table. This new table is created with the following configuration:

+- The table is [Append-Only](https://github.com/delta-io/delt#append-only-tables)

+- The table schema is created with the schema of the first record encountered.

+All records of output data are projected to the schema of the existing table. If the output is being written to a new delta table, the table schema is created with the first record. If the incoming data has one extra column compared to the existing table schema, it's written in the table without the extra column. If the incoming data is missing one column compared to the existing table schema, it's written in the table with the column being null.

+If there's no intersection between the schema of the delta table and the schema of a record of the streaming job, it's considered an instance of schema conversion failure. It isn't the only case that would be considered schema conversion failure.

+At the failure of schema conversion, the job behavior follows the [output data error handing policy](stream-analytics-output-error-policy.md) configured at the job level.

+The Stream Analytics job creates [Delta Log checkpoints](https://github.com/delta-io/delt#checkpoints-1) periodically in the V1 format. Delta Log checkpoints are snapshots of the Delta Table and typically contain the name of the data file generated by the Stream Analytics job. If the number of data files is large, then it leads to large checkpoints, which can cause memory issues in the Stream Analytics Job.

+- Multiple partition columns aren't supported. If multiple partition columns are desired, the recommendation is to use a composite key in the query and then specify it as the partition column.

+- Small file compaction isn't performed by Stream Analytics.

+- All data files are created without compression.

+- The [Date and Decimal types](https://github.com/delta-io/delt#valid-feature-names-in-table-features) aren't supported.

+- Writing to existing tables of Writer Version 7 or above with writer features fail.

+ - Example: Writing to existing tables with [Deletion Vectors](https://github.com/delta-io/delt#deletion-vectors) enabled fail.

+ - The number of Add File Actions generated are determined by many factors:

+ - Size of the batch. It's determined by the data volume and the batching parameters [Minimum Rows and Maximum Time](blob-storage-azure-data-lake-gen2-output.md#output-configuration)

+ - Cardinality of the [Partition Column values](#delta-lake-configuration) of the batch.

+ - Reduce the batching configurations [Minimum Rows and Maximum Time](blob-storage-azure-data-lake-gen2-output.md#output-configuration)

+ - Reduce the cardinality of the [Partition Column values](#delta-lake-configuration) by tweaking the input data or choosing a different partition column

+- Stream Analytics jobs can only read and write single part V1 Checkpoints. Multi-part checkpoints and the Checkpoint V2 format aren't supported.

+* [Capture data from Event Hubs in Delta Lake format](capture-event-hub-data-delta-lake.md)

+1. [Install the Apache Spark 2.4.0 helm chart](https://artifacthub.io/packages/helm/microsoft/spark) - warning: [Spark 2.4](../spark/apache-spark-24-runtime.md) is retired and out of the support.

+ "extensionProfile" : {

+ "extensions" : [

+ "name": "HealthExtension",

+ "properties": {

+ "publisher": "Microsoft.ManagedServices",

+ "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",

+ "autoUpgradeMinorVersion": true,

+ "typeHandlerVersion": "1.0",

+ "settings": {

+ "protocol": "<protocol>",

+ "port": <port>,

+ "requestPath": "</requestPath>",

+ "intervalInSeconds": 5,

+ "numberOfProbes": 1

+ }

+ }

+ ]

+}

+ "extensionProfile" : {

+ "extensions" : [

+ "name": "HealthExtension",

+ "properties": {

+ "publisher": "Microsoft.ManagedServices",

+ "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",

+ "autoUpgradeMinorVersion": true,

+ "typeHandlerVersion": "2.0",

+ "settings": {

+ "protocol": "<protocol>",

+ "port": <port>,

+ "requestPath": "</requestPath>",

+ "intervalInSeconds": 5,

+ "numberOfProbes": 1,

+ "gracePeriod": 600

+ }

+ }

+ ]

+}

+#### Example 1

+#### Example 2

+To update your scale set to use a different OS version, you need to set all the updated properties in a single call. In this example, we are changing from Windows Server 2016 to Windows Server 2019.

+```powershell

+$VMSS = Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myScaleSet"

+Set-AzVmssStorageProfile $vmss `

+ -OsDiskCreateOption "FromImage" `

+ -ImageReferencePublisher "MicrosoftWindowsServer" `

+ -ImageReferenceOffer "WindowsServer" `

+ -ImageReferenceSku "2019-datacenter" `

+ -ImageReferenceVersion "latest"

+Update-AzVmss -ResourceGroupName "myResourceGroup" -Name "myScaleSet" -VirtualMachineScaleSet $VMSS

+```

+A fault domain is a fault isolation group within an availability zone or datacenter of hardware nodes that share the same power, networking, cooling, and platform maintenance schedule. VM instances that are on different fault domains are not likely to be impacted by the same planned or unplanned outage. You can specify how instances are spread across fault domains within a region or zone.

+ "extensionProfile" : {

+ "extensions" : [

+ "name": "HealthExtension",

+ "properties": {

+ "publisher": "Microsoft.ManagedServices",

+ "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",

+ "autoUpgradeMinorVersion": true,

+ "typeHandlerVersion": "1.0",

+ "settings": {

+ "protocol": "<protocol>",

+ "port": <port>,

+ "requestPath": "</requestPath>",

+ "intervalInSeconds": 5,

+ "numberOfProbes": 1

+ }

+ }

+ ]

+}

+ "extensionProfile" : {

+ "extensions" : [

+ "name": "HealthExtension",

+ "properties": {

+ "publisher": "Microsoft.ManagedServices",

+ "type": "<ApplicationHealthLinux or ApplicationHealthWindows>",

+ "autoUpgradeMinorVersion": true,

+ "typeHandlerVersion": "2.0",

+ "settings": {

+ "protocol": "<protocol>",

+ "port": <port>,

+ "requestPath": "</requestPath>",

+ "intervalInSeconds": 5,

+ "numberOfProbes": 1,

+ "gracePeriod": 600

+ }

+ }

+ ]

+}

+ Title: Manage Network Watcher Agent VM extension - Windows

+#CustomerIntent: As an Azure administrator, I want to learn about Network Watcher Agent VM extension so that I can use Network watcher features to diagnose and monitor my virtual machines (VMs).

+# Manage Network Watcher Agent virtual machine extension for Windows

+[Azure Network Watcher](../../network-watcher/network-watcher-monitoring-overview.md) is a network performance monitoring, diagnostic, and analytics service that allows monitoring for Azure networks. The Network Watcher Agent virtual machine extension is a requirement for some of the Network Watcher features on Azure virtual machines (VMs). For more information, see [Network Watcher Agent FAQ](../../network-watcher/frequently-asked-questions.yml#network-watcher-agent).

+In this article, you learn about the supported platforms and deployment options for the Network Watcher Agent VM extension for Windows. Installation of the agent doesn't disrupt, or require a reboot of the virtual machine. You can install the extension on virtual machines that you deploy. If the virtual machine is deployed by an Azure service, check the documentation for the service to determine whether or not it permits installing extensions in the virtual machine.

+# [**Portal**](#tab/portal)

+- An Azure Windows virtual machine (VM). For more information, see [Supported Windows versions](#supported-operating-systems).

+- Internet connectivity: some of the Network Watcher Agent functionality requires that the virtual machine is connected to the Internet. For example, without the ability to establish outgoing connections, the Network Watcher Agent can't upload packet captures to your storage account. For more information, see [Packet capture overview](../../network-watcher/packet-capture-overview.md).

+# [**PowerShell**](#tab/powershell)

+- An Azure Windows virtual machine (VM). For more information, see [Supported Windows versions](#supported-operating-systems).

+- Internet connectivity: some of the Network Watcher Agent functionality requires that the virtual machine is connected to the Internet. For example, without the ability to establish outgoing connections, the Network Watcher Agent can't upload packet captures to your storage account. For more information, see [Packet capture overview](../../network-watcher/packet-capture-overview.md).

+- Azure Cloud Shell or Azure PowerShell.

+ The steps in this article run the Azure PowerShell cmdlets interactively in [Azure Cloud Shell](/azure/cloud-shell/overview). To run the commands in the Cloud Shell, select **Open Cloud Shell** at the upper-right corner of a code block. Select **Copy** to copy the code and then paste it into Cloud Shell to run it. You can also run the Cloud Shell from within the Azure portal.

+ You can also [install Azure PowerShell locally](/powershell/azure/install-azure-powershell) to run the cmdlets. This article requires the Azure PowerShell `Az` module. To find the installed version, run `Get-Module -ListAvailable Az`. If you run PowerShell locally, sign in to Azure using the [Connect-AzAccount](/powershell/module/az.accounts/connect-azaccount) cmdlet.

+# [**Azure CLI**](#tab/cli)

+- An Azure Windows virtual machine (VM). For more information, see [Supported Windows versions](#supported-operating-systems).

+- Internet connectivity: some of the Network Watcher Agent functionality requires that the virtual machine is connected to the Internet. For example, without the ability to establish outgoing connections, the Network Watcher Agent can't upload packet captures to your storage account. For more information, see [Packet capture overview](../../network-watcher/packet-capture-overview.md).

+- Azure Cloud Shell or Azure CLI.

+ The steps in this article run the Azure CLI commands interactively in [Azure Cloud Shell](/azure/cloud-shell/overview). To run the commands in the Cloud Shell, select **Open Cloud Shell** at the upper-right corner of a code block. Select **Copy** to copy the code, and paste it into Cloud Shell to run it. You can also run the Cloud Shell from within the Azure portal.

+ You can also [install Azure CLI locally](/cli/azure/install-azure-cli) to run the commands. If you run Azure CLI locally, sign in to Azure using the [az login](/cli/azure/reference-index#az-login) command.

+# [**Resource Manager**](#tab/arm)

+- An Azure Windows virtual machine (VM). For more information, see [Supported Windows versions](#supported-operating-systems).

+- Internet connectivity: some of the Network Watcher Agent functionality requires that the virtual machine is connected to the Internet. For example, without the ability to establish outgoing connections, the Network Watcher Agent can't upload packet captures to your storage account. For more information, see [Packet capture overview](../../network-watcher/packet-capture-overview.md).

+- Azure PowerShell or Azure CLI installed locally to deploy the template.

+ - You can [install Azure PowerShell locally](/powershell/azure/install-azure-powershell) to run the cmdlets. Use [Connect-AzAccount](/powershell/module/az.accounts/connect-azaccount) cmdlet to sign in to Azure.

+ - You can [install Azure CLI locally](/cli/azure/install-azure-cli) to run the commands. Use [az login](/cli/azure/reference-index#az-login) command to sign in to Azure.

+## Supported operating systems

+Network Watcher Agent extension for Windows can be installed on Windows Server 2012, 2012 R2, 2016, 2019 and 2022 releases. Currently, Nano Server isn't supported.

+ "type": "Microsoft.Compute/virtualMachines/extensions",

+ "apiVersion": "2023-03-01",

+ "[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"

+```

+## List installed extensions

+# [**Portal**](#tab/portal)

+From the virtual machine page in the Azure portal, you can view the installed extension by following these steps:

+1. Under **Settings**, select **Extensions + applications**.

+1. In the **Extensions** tab, you can see all installed extensions on the virtual machine. If the list is long, you can use the search box to filter the list.

+ :::image type="content" source="./media/network-watcher/list-vm-extensions.png" alt-text="Screenshot that shows how to view installed extensions on a VM in the Azure portal." lightbox="./media/network-watcher/list-vm-extensions.png":::

+# [**PowerShell**](#tab/powershell)

+Use [Get-AzVMExtension](/powershell/module/az.compute/get-azvmextension) cmdlet to list all installed extensions on the virtual machine:

+```azurepowershell-interactive

+# List the installed extensions on the virtual machine.

+Get-AzVMExtension -VMName 'myVM' -ResourceGroupName 'myResourceGroup' | format-table Name, Publisher, ExtensionType, EnableAutomaticUpgrade

+The output of the cmdlet lists the installed extensions:

+```output

+Name Publisher ExtensionType EnableAutomaticUpgrade

+- - -

+AzureNetworkWatcherExtension Microsoft.Azure.NetworkWatcher NetworkWatcherAgentWindows True

+AzurePolicyforWindows Microsoft.GuestConfiguration ConfigurationforWindows True

+```

+# [**Azure CLI**](#tab/cli)

+Use [az vm extension list](/cli/azure/vm/extension#az-vm-extension-list) command to list all installed extensions on the virtual machine:

+```azurecli

+# List the installed extensions on the virtual machine.

+az vm extension list --resource-group 'myResourceGroup' --vm-name 'myVM' --out table

+```

+The output of the command lists the installed extensions:

+```output

+Name ProvisioningState Publisher Version AutoUpgradeMinorVersion

+- - -

+AzureNetworkWatcherExtension Succeeded Microsoft.Azure.NetworkWatcher 1.4 True

+AzurePolicyforWindows Succeeded Microsoft.GuestConfiguration 1.1 True

+# [**Resource Manager**](#tab/arm)

+N/A

+## Install Network Watcher Agent VM extension

+# [**Portal**](#tab/portal)

+From the virtual machine page in the Azure portal, you can install the Network Watcher Agent VM extension by following these steps:

+1. Under **Settings**, select **Extensions + applications**.

+1. Select **+ Add** and search for **Network Watcher Agent** and install it. If the extension is already installed, you can see it in the list of extensions.

+ :::image type="content" source="./media/network-watcher/vm-extensions.png" alt-text="Screenshot that shows the VM's extensions page in the Azure portal." lightbox="./media/network-watcher/vm-extensions.png":::

+1. In the search box of **Install an Extension**, enter *Network Watcher Agent for Windows*. Select the extension from the list and select **Next**.

+ :::image type="content" source="./media/network-watcher/install-extension-windows.png" alt-text="Screenshot that shows how to install Network Watcher Agent for Windows in the Azure portal." lightbox="./media/network-watcher/install-extension-windows.png":::

+1. Select **Review + create** and then select **Create**.

+# [**PowerShell**](#tab/powershell)

+Use [Set-AzVMExtension](/powershell/module/az.compute/set-azvmextension) cmdlet to install Network Watcher Agent VM extension on the virtual machine:

+```azurepowershell-interactive

+# Install Network Watcher Agent for Windows on the virtual machine.

+Set-AzVMExtension -Name 'AzureNetworkWatcherExtension' -Publisher 'Microsoft.Azure.NetworkWatcher' -ExtensionType 'NetworkWatcherAgentWindows' -EnableAutomaticUpgrade 1 -TypeHandlerVersion '1.4' -ResourceGroupName 'myResourceGroup' -VMName 'myVM'

+```

+Once the installation is successfully completed, you see the following output:

+```output

+RequestId IsSuccessStatusCode StatusCode ReasonPhrase

+ - -

+ True OK

+```

+# [**Azure CLI**](#tab/cli)

+Use [az vm extension set](/cli/azure/vm/extension#az-vm-extension-set) command to install Network Watcher Agent VM extension on the virtual machine:

+```azurecli

+# Install Network Watcher Agent for Windows on the virtual machine.

+az vm extension set --name 'NetworkWatcherAgentWindows' --extension-instance-name 'AzureNetworkWatcherExtension' --publisher 'Microsoft.Azure.NetworkWatcher' --enable-auto-upgrade 'true' --version '1.4' --resource-group 'myResourceGroup' --vm-name 'myVM'

+# [**Resource Manager**](#tab/arm)

+Use the following Azure Resource Manager template (ARM template) to install Network Watcher Agent VM extension on a Windows virtual machine:

+```json

+{

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

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "vmName": {

+ "type": "string"

+ }

+ },

+ "variables": {},

+ "resources": [

+ {

+ "name": "[parameters('vmName')]",

+ "type": "Microsoft.Compute/virtualMachines",

+ "apiVersion": "2023-03-01",

+ "location": "[resourceGroup().location]",

+ "properties": {

+ }

+ },

+ {

+ "name": "[concat(parameters('vmName'), '/AzureNetworkWatcherExtension')]",

+ "type": "Microsoft.Compute/virtualMachines/extensions",

+ "apiVersion": "2023-03-01",

+ "location": "[resourceGroup().location]",

+ "dependsOn": [

+ "[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"

+ ],

+ "properties": {

+ "autoUpgradeMinorVersion": true,

+ "publisher": "Microsoft.Azure.NetworkWatcher",

+ "type": "NetworkWatcherAgentWindows",

+ "typeHandlerVersion": "1.4"

+ }

+ }

+ ],

+ "outputs": {}

+}

+You can use either Azure PowerShell or Azure CLI to deploy the Resource Manager template:

+```azurepowershell

+# Deploy the JSON template file using Azure PowerShell.

+New-AzResourceGroupDeployment -ResourceGroupName 'myResourceGroup' -TemplateFile 'agent.json'

+```

+```azurecli

+# Deploy the JSON template file using the Azure CLI.

+az deployment group create --resource-group 'myResourceGroup' --template-file

+```

+## Uninstall Network Watcher Agent VM extension

+# [**Portal**](#tab/portal)

+From the virtual machine page in the Azure portal, you can uninstall the Network Watcher Agent VM extension by following these steps:

+1. Under **Settings**, select **Extensions + applications**.

+1. Select **AzureNetworkWatcherExtension** from the list of extensions, and then select **Uninstall**.

+ :::image type="content" source="./media/network-watcher/uninstall-extension-windows.png" alt-text="Screenshot that shows how to uninstall Network Watcher Agent for Windows in the Azure portal." lightbox="./media/network-watcher/uninstall-extension-windows.png":::

+ > [!NOTE]

+ > In the list of extensions, you might see Network Watcher Agent VM extension named differently than **AzureNetworkWatcherExtension**.

+# [**PowerShell**](#tab/powershell)

+Use [Remove-AzVMExtension](/powershell/module/az.compute/remove-azvmextension) cmdlet to remove Network Watcher Agent VM extension from the virtual machine:

+```azurepowershell-interactive

+# Uninstall Network Watcher Agent VM extension.

+Remove-AzureVMExtension -Name 'AzureNetworkWatcherExtension' -ResourceGroupName 'myResourceGroup' -VMName 'myVM'

+```

+# [**Azure CLI**](#tab/cli)

+Use [az vm extension delete](/cli/azure/vm/extension#az-vm-extension-delete) command to remove Network Watcher Agent VM extension from the virtual machine:

+```azurecli-interactive

+# Uninstall Network Watcher Agent VM extension.

+az vm extension delete --name 'AzureNetworkWatcherExtension' --resource-group 'myResourceGroup' --vm-name 'myVM'

+```

+# [**Resource Manager**](#tab/arm)

+N/A

+- [Update Azure Network Watcher extension to the latest version](network-watcher-update.md).

+ Title: Monitoring data reference for Azure Virtual Machines

+description: This article contains important reference material you need when you monitor Azure Virtual Machines.

+# Azure Virtual Machines monitoring data reference

+See [Monitor Azure Virtual Machines](monitor-vm.md) for details on the data you can collect for Azure Virtual Machines and how to use it.

+>[!IMPORTANT]

+>Metrics for the guest operating system (guest OS) that runs in a virtual machine (VM) aren't listed here. Guest OS metrics must be collected through one or more agents that run on or as part of the guest operating system. Guest OS metrics include performance counters that track guest CPU percentage or memory usage, both of which are frequently used for autoscaling or alerting.

+>

+>Host OS metrics are available and listed in the following tables. Host OS metrics relate to the Hyper-V session that's hosting your guest OS session. For more information, see [Guest OS and host OS metrics](/azure/azure-monitor/reference/supported-metrics/metrics-index#guest-os-and-host-os-metrics).

+### Supported metrics for Microsoft.Compute/virtualMachines

+The following table lists the metrics available for the Microsoft.Compute/virtualMachines resource type.

+### VM availability metric (preview)

+| 0 | VM is unavailable. The VM could be stopped or rebooting. If you shut down a VM from within the VM, it emits this value. |

+| Null | State of the VM is unknown. If you stop a VM from the Azure portal, CLI, or PowerShell, it immediately stops emitting the availability metric, and you see null values. |

+The dimension Logical Unit Number (`LUN`) is associated with some of the preceding metrics.

+### Supported resource logs for Microsoft.Compute/virtualMachines

+> [!IMPORTANT]

+> For Azure VMs, all the important data is collected by the Azure Monitor agent. The resource log categories available for Azure VMs aren't important and aren't available for collection from the Azure portal. For detailed information about how the Azure Monitor agent collects VM log data, see [Monitor virtual machines with Azure Monitor: Collect data](/azure/azure-monitor/vm/monitor-virtual-machine-data-collection).

+| Table | Categories | Solutions|[Supports basic log plan](/azure/azure-monitor/logs/basic-logs-configure?tabs=portal-1#compare-the-basic-and-analytics-log-data-plans)| Queries|

+||||||

+| [ADAssessmentRecommendation](/azure/azure-monitor/reference/tables/ADAssessmentRecommendation)<br>Recommendations generated by AD assessments that are started through a scheduled task. When you schedule the assessment it runs by default every seven days and uploads the data into Azure Log Analytics. | workloads | ADAssessment, ADAssessmentPlus, AzureResources | No| [Yes](/azure/azure-monitor/reference/queries/adassessmentrecommendation)|

+| [ADReplicationResult](/azure/azure-monitor/reference/tables/ADReplicationResult)<br>The AD Replication Status solution regularly monitors your Active Directory environment for any replication failures. | workloads | ADReplication, AzureResources | No| -|

+| [AzureActivity](/azure/azure-monitor/reference/tables/AzureActivity)<br>Entries from the Azure Activity log that provides insight into any subscription-level or management group level events that have occurred in Azure. | resources, audit, security | LogManagement | No| [Yes](/azure/azure-monitor/reference/queries/azureactivity)|

+| [AzureMetrics](/azure/azure-monitor/reference/tables/AzureMetrics)<br>Metric data emitted by Azure services that measure their health and performance. | resources | LogManagement | No| [Yes](/azure/azure-monitor/reference/queries/azuremetrics)|

+| [CommonSecurityLog](/azure/azure-monitor/reference/tables/CommonSecurityLog)<br>This table is for collecting events in the Common Event Format, that are most often sent from different security appliances such as Check Point, Palo Alto and more. | security | Security, SecurityInsights | No| [Yes](/azure/azure-monitor/reference/queries/commonsecuritylog)|

+| [ComputerGroup](/azure/azure-monitor/reference/tables/ComputerGroup)<br>Computer groups that can be used to scope log queries to a set of computers. Includes the computers in each group. | monitor, virtualmachines, management | LogManagement | No| -|

+| [ConfigurationChange](/azure/azure-monitor/reference/tables/ConfigurationChange)<br>View changes to in-guest configuration data such as Files Software Registry Keys Windows Services and Linux Daemons | management | ChangeTracking | No| [Yes](/azure/azure-monitor/reference/queries/configurationchange)|

+| [ConfigurationData](/azure/azure-monitor/reference/tables/ConfigurationData)<br>View the last reported state for in-guest configuration data such as Files Software Registry Keys Windows Services and Linux Daemons | management | ChangeTracking | No| [Yes](/azure/azure-monitor/reference/queries/configurationdata)|

+| [ContainerLog](/azure/azure-monitor/reference/tables/ContainerLog)<br>Log lines collected from stdout and stderr streams for containers. | container, applications | AzureResources, ContainerInsights, Containers | No| [Yes](/azure/azure-monitor/reference/queries/containerlog)|

+| [DnsEvents](/azure/azure-monitor/reference/tables/DnsEvents) | network | DnsAnalytics, SecurityInsights | No| [Yes](/azure/azure-monitor/reference/queries/dnsevents)|

+| [DnsInventory](/azure/azure-monitor/reference/tables/DnsInventory) | network | DnsAnalytics, SecurityInsights | No| -|

+| [Event](/azure/azure-monitor/reference/tables/Event)<br>Events from Windows Event Log on Windows computers using the Log Analytics agent. | virtualmachines | LogManagement | No| [Yes](/azure/azure-monitor/reference/queries/event)|

+| [HealthStateChangeEvent](/azure/azure-monitor/reference/tables/HealthStateChangeEvent)<br>Workload Monitor Health. This data represents state transitions of a health monitor. | undefined | AzureResources, VMInsights | No| -|

+| [Heartbeat](/azure/azure-monitor/reference/tables/Heartbeat)<br>Records logged by Log Analytics agents once per minute to report on agent health. | virtualmachines, container, management | LogManagement | No| [Yes](/azure/azure-monitor/reference/queries/heartbeat)|

+| [InsightsMetrics](/azure/azure-monitor/reference/tables/InsightsMetrics)<br>Table that stores metrics. 'Perf' table also stores many metrics and over time they all will converge to InsightsMetrics for Azure Monitor Solutions | virtualmachines, container, resources | AzureResources, ContainerInsights, InfrastructureInsights, LogManagement, ServiceMap, VMInsights | No| [Yes](/azure/azure-monitor/reference/queries/insightsmetrics)|

+| [Perf](/azure/azure-monitor/reference/tables/Perf)<br>Performance counters from Windows and Linux agents that provide insight into the performance of hardware components operating systems and applications. | virtualmachines, container | LogManagement | No| [Yes](/azure/azure-monitor/reference/queries/perf)|

+| [ProtectionStatus](/azure/azure-monitor/reference/tables/ProtectionStatus)<br>Antimalware installation info and security health status of the machine: | security | AntiMalware, Security, SecurityCenter, SecurityCenterFree | No| [Yes](/azure/azure-monitor/reference/queries/protectionstatus)|

+| [SQLAssessmentRecommendation](/azure/azure-monitor/reference/tables/SQLAssessmentRecommendation)<br>Recommendations generated by SQL assessments that are started through a scheduled task. When you schedule the assessment it runs by default every seven days and uploads the data into Azure Log Analytics. | workloads | AzureResources, SQLAssessment, SQLAssessmentPlus | No| [Yes](/azure/azure-monitor/reference/queries/sqlassessmentrecommendation)|

+| [SecurityBaseline](/azure/azure-monitor/reference/tables/SecurityBaseline) | security | Security, SecurityCenter, SecurityCenterFree | No| -|

+| [SecurityBaselineSummary](/azure/azure-monitor/reference/tables/SecurityBaselineSummary) | security | Security, SecurityCenter, SecurityCenterFree | No| -|

+| [SecurityEvent](/azure/azure-monitor/reference/tables/SecurityEvent)<br>Security events collected from windows machines by Azure Security Center or Azure Sentinel. | security | Security, SecurityInsights | No| [Yes](/azure/azure-monitor/reference/queries/securityevent)|

+| [Syslog](/azure/azure-monitor/reference/tables/Syslog)<br>Syslog events on Linux computers using the Log Analytics agent. | virtualmachines, security | LogManagement | No| [Yes](/azure/azure-monitor/reference/queries/syslog)|

+| [Update](/azure/azure-monitor/reference/tables/Update)<br>Details for update schedule run. Includes information such as which updates where available and which were installed. | management, security | Security, SecurityCenter, SecurityCenterFree, Updates | No| [Yes](/azure/azure-monitor/reference/queries/update)|

+| [UpdateRunProgress](/azure/azure-monitor/reference/tables/UpdateRunProgress)<br>Breaks down each run of your update schedule by the patches available at the time with details on the installation status of each patch. | management | Updates | No| [Yes](/azure/azure-monitor/reference/queries/updaterunprogress)|

+| [UpdateSummary](/azure/azure-monitor/reference/tables/UpdateSummary)<br>Summary for each update schedule run. Includes information such as how many updates weren't installed. | virtualmachines | Security, SecurityCenter, SecurityCenterFree, Updates | No| [Yes](/azure/azure-monitor/reference/queries/updatesummary)|

+| [VMBoundPort](/azure/azure-monitor/reference/tables/VMBoundPort)<br>Traffic for open server ports on the monitored machine. | virtualmachines | AzureResources, InfrastructureInsights, ServiceMap, VMInsights | No| -|

+| [VMComputer](/azure/azure-monitor/reference/tables/VMComputer)<br>Inventory data for servers collected by the Service Map and VM insights solutions using the Dependency agent and Log analytics agent. | virtualmachines | AzureResources, ServiceMap, VMInsights | No| -|

+| [VMConnection](/azure/azure-monitor/reference/tables/VMConnection)<br>Traffic for inbound and outbound connections to and from monitored computers. | virtualmachines | AzureResources, InfrastructureInsights, ServiceMap, VMInsights | No| -|

+| [VMProcess](/azure/azure-monitor/reference/tables/VMProcess)<br>Process data for servers collected by the Service Map and VM insights solutions using the Dependency agent and Log analytics agent. | virtualmachines | AzureResources, ServiceMap, VMInsights | No| -|

+| [W3CIISLog](/azure/azure-monitor/reference/tables/W3CIISLog)<br>Internet Information Server (IIS) log on Windows computers using the Log Analytics agent. | management, virtualmachines | LogManagement | No| [Yes](/azure/azure-monitor/reference/queries/w3ciislog)|

+| [WindowsFirewall](/azure/azure-monitor/reference/tables/WindowsFirewall) | security | Security, WindowsFirewall | No| -|

+| [WireData](/azure/azure-monitor/reference/tables/WireData)<br>Network data collected by the WireData solution using by the Dependency agent and Log analytics agent. | virtualmachines, security | WireData, WireData2 | No| [Yes](/azure/azure-monitor/reference/queries/wiredata)|

+The following table lists a few example operations that relate to creating VMs in the activity log. For a complete list of operations, see [Microsoft.Compute resource provider operations](/azure/role-based-access-control/resource-provider-operations#microsoftcompute).

+## Related content

+- See [Monitor Virtual Machines](monitor-vm.md) for a description of monitoring Virtual Machines.

+- See [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for details on monitoring Azure resources.

+ Title: Monitor Azure Virtual Machines

+description: Start here to learn how to monitor Azure Virtual Machines and Virtual Machine Scale Sets.

+#customer intent: As a cloud administrator, I want to understand how to monitor Azure virtual machines so that I can ensure the health and performance of my virtual machines and applications.

+# Monitor Azure Virtual Machines

+This article provides an overview of how to monitor the health and performance of Azure virtual machines (VMs).

+>[!NOTE]

+>This article provides basic information to help you get started with monitoring Azure Virtual Machines. For a complete guide to monitoring your entire environment of Azure and hybrid virtual machines, see the [Monitor virtual machines deployment guide](/azure/azure-monitor/vm/monitor-virtual-machine).

+## Overview: Monitor VM host and guest metrics and logs

+You can collect metrics and logs from the **VM host**, which is the physical server and hypervisor that creates and manages the VM, and from the **VM guest**, which includes the operating system and applications that run inside the VM.

+VM host and guest data is useful in different scenarios:

+| Data type | Scenarios | Data collection | Available data |

+|-|-|-|-|

+| **VM host data** | Monitor the stability, health, and efficiency of the physical host on which the VM is running.<br>(Optional) [Scale up or scale down](/azure/azure-monitor/autoscale/autoscale-overview) based on the load on your application.| Available by default without any additional setup. |[Host performance metrics](#azure-monitor-platform-metrics)<br><br>[Activity logs](#azure-activity-log)<br><br>[Boot diagnostics](#boot-diagnostics)|

+| **VM guest data: overview** | Analyze and troubleshoot performance and operational efficiency of workloads running in your Azure environment. | Install [Azure Monitor Agent](/azure/azure-monitor/agents/agents-overview) on the VM and set up a [data collection rule (DCR)](#data-collection-rules). |See various levels of data in the following rows.|

+|**Basic VM guest data**|[VM insights](#vm-insights) is a quick and easy way to start monitoring your VM clients, especially useful for exploring overall VM usage and performance when you don't yet know the metric of primary interest.|[Enable VM insights](/azure/azure-monitor/vm/vminsights-enable-overview) to automatically install Azure Monitor Agent and create a predefined DCR.|[Guest performance counters](/azure/azure-monitor/vm/vminsights-performance)<br><br>[Dependencies between application components running on the VM](/azure/azure-monitor/vm/vminsights-maps)|

+|**VM operating system monitoring data**|Monitor application performance and events, resource consumption by specific applications and processes, and operating system-level performance and events. Valuable for troubleshooting application-specific issues, optimizing resource usage within VMs, and ensuring optimal performance for workloads running inside VMs.|Install [Azure Monitor Agent](/azure/azure-monitor/agents/agents-overview) on the VM and set up a [DCR](#data-collection-rules).|[Guest performance counters](/azure/azure-monitor/agents/data-collection-rule-azure-monitor-agent)<br><br>[Windows events](/azure/azure-monitor/agents/data-collection-rule-azure-monitor-agent)<br><br>[Syslog events](/azure/azure-monitor/agents/data-collection-syslog)|

+|**Advanced/custom VM guest data**|Monitoring of web servers, Linux appliances, and any type of data you want to collect from a VM. |Install [Azure Monitor Agent](/azure/azure-monitor/agents/agents-overview) on the VM and set up a [DCR](#data-collection-rules).|[IIS logs](/azure/azure-monitor/agents/data-collection-iis)<br><br>[SNMP traps](/azure/azure-monitor/agents/data-collection-snmp-data)<br><br>[Any data written to a text or JSON file](/azure/azure-monitor/agents/data-collection-text-log)|

+### VM insights

+VM insights monitors your Azure and hybrid virtual machines in a single interface. VM insights provides the following benefits for monitoring VMs in Azure Monitor:

+- Simplified onboarding of the Azure Monitor agent and the Dependency agent, so that you can monitor a virtual machine (VM) guest operating system and workloads.

+- Predefined data collection rules that collect the most common set of performance data.

+- Predefined trending performance charts and workbooks, so that you can analyze core performance metrics from the virtual machine's guest operating system.

+- The Dependency map, which displays processes that run on each virtual machine and the interconnected components with other machines and external sources.

+For a tutorial on enabling VM insights for a virtual machine, see [Enable monitoring with VM insights for Azure virtual machine](/azure/azure-monitor/vm/tutorial-monitor-vm-enable-insights). For general information about enabling insights and a variety of methods for onboarding VMs, see [Enable VM insights overview](/azure/azure-monitor/vm/vminsights-enable-overview).

+If you enable VM insights, the Azure Monitor agent is installed and starts sending a predefined set of performance data to Azure Monitor Logs. You can create other data collection rules to collect events and other performance data. To learn how to install the Azure Monitor agent and create a data collection rule (DCR) that defines the data to collect, see [Tutorial: Collect guest logs and metrics from an Azure virtual machine](/azure/azure-monitor/vm/tutorial-monitor-vm-guest).

+For more information about the resource types for Virtual Machines, see [Azure Virtual Machines monitoring data reference](monitor-vm-reference.md).

+Platform metrics for Azure VMs include important *host metrics* such as CPU, network, and disk utilization. Host OS metrics relate to the Hyper-V session that's hosting a guest operating system (guest OS) session.

+Metrics for the *guest OS* that runs in a VM must be collected through one or more agents, such as the [Azure Monitor agent](/azure/azure-monitor/agents/azure-monitor-agent-overview), that run on or as part of the guest OS. Guest OS metrics include performance counters that track guest CPU percentage or memory usage, both of which are frequently used for autoscaling or alerting. For more information, see [Guest OS and host OS metrics](/azure/azure-monitor/reference/supported-metrics/metrics-index#guest-os-and-host-os-metrics).

+For detailed information about how the Azure Monitor agent collects VM monitoring data, see [Monitor virtual machines with Azure Monitor: Collect data](/azure/azure-monitor/vm/monitor-virtual-machine-data-collection).

+For a list of available metrics for Virtual Machines, see [Virtual Machines monitoring data reference](monitor-vm-reference.md#metrics).

+- For the available resource log categories, their associated Log Analytics tables, and the logs schemas for Virtual Machines, see [Virtual Machines monitoring data reference](monitor-vm-reference.md).

+> [!IMPORTANT]

+> For Azure VMs, all the important data is collected by the Azure Monitor agent. The resource log categories available for Azure VMs aren't important and aren't available for collection from the Azure portal. For detailed information about how the Azure Monitor agent collects VM log data, see [Monitor virtual machines with Azure Monitor: Collect data](/azure/azure-monitor/vm/monitor-virtual-machine-data-collection).

+## Data collection rules

+[Data collection rules (DCRs)](/azure/azure-monitor/essentials/data-collection-rule-overview) define data collection from the Azure Monitor Agent and are stored in your Azure subscription. For VMs, DCRs define data such as events and performance counters to collect, and specify locations such as Log Analytics workspaces to send the data. A single VM can be associated with multiple DCRs, and a single DCR can be associated with multiple VMs.

+### VM insights DCR

+VM insights creates a DCR that collects common performance counters for the client operating system and sends them to the [InsightsMetrics](/azure/azure-monitor/reference/tables/insightsmetrics) table in the Log Analytics workspace. For a list of performance counters collected, see [How to query logs from VM insights](/azure/azure-monitor/vm/vminsights-log-query#performance-records). You can use this DCR with other VMs instead of creating a new DCR for each VM.

+You can also optionally enable collection of processes and dependencies, which populates the following tables and enables the VM insights Map feature.

+- [VMBoundPort](/azure/azure-monitor/reference/tables/vmboundport): Traffic for open server ports on the machine

+- [VMComputer](/azure/azure-monitor/reference/tables/vmcomputer): Inventory data for the machine

+- [VMConnection](/azure/azure-monitor/reference/tables/vmconnection): Traffic for inbound and outbound connections to and from the machine

+- [VMProcess](/azure/azure-monitor/reference/tables/vmprocess): Processes running on the machine

+### Collect performance counters

+VM insights collects a common set of performance counters in Logs to support its performance charts. If you aren't using VM insights, or want to collect other counters or send them to other destinations, you can create other DCRs. You can quickly create a DCR by using the most common counters.

+You can send performance data from the client to either Azure Monitor Metrics or Azure Monitor Logs. VM insights sends performance data to the [InsightsMetrics](/azure/azure-monitor/reference/tables/insightsmetrics) table. Other DCRs send performance data to the [Perf](/azure/azure-monitor/reference/tables/perf) table. For guidance on creating a DCR to collect performance counters, see [Collect events and performance counters from virtual machines with Azure Monitor Agent](/azure/azure-monitor/agents/data-collection-rule-azure-monitor-agent).

+### Query logs from VM insights

+VM insights stores the data it collects in Azure Monitor Logs, and the insights provide performance and map views that you can use to interactively analyze the data. You can work directly with this data to drill down further or perform custom analyses. For more information and to get sample queries for this data, see [How to query logs from VM insights](/azure/azure-monitor/vm/vminsights-log-query).

+To analyze log data that you collect from your VMs, you can use [log queries](/azure/azure-monitor/logs/get-started-queries) in [Log Analytics](/azure/azure-monitor/logs/log-analytics-tutorial). Several [built-in queries](/azure/azure-monitor/logs/queries) for VMs are available to use, or you can create your own queries. You can interactively work with the results of these queries, include them in a workbook to make them available to other users, or generate alerts based on their results.

+To access built-in Kusto queries for your VM, select **Logs** in the **Monitoring** section of the left navigation on your VM's Azure portal page. On the **Logs** page, select the **Queries** tab, and then select the query to run.

+You can create a single multi-resource alert rule that applies to all VMs in a particular resource group or subscription within the same region. See [Create availability alert rule for Azure virtual machine (preview)](/azure/azure-monitor/vm/tutorial-monitor-vm-alert-availability) for a tutorial using the availability metric.

+Recommended alert rules for Azure VMs include the [VM availability metric](monitor-vm-reference.md#vm-availability-metric-preview), which alerts when a VM stops running.

+For more information, see [Tutorial: Enable recommended alert rules for Azure virtual machine](/azure/azure-monitor/vm/tutorial-monitor-vm-alert-recommended).

+### Common alert rules

+To see common VM log alert rules in the Azure portal, go to the **Queries** pane in Log Analytics. For **Resource type**, enter **Virtual machines**, and for **Type**, enter **Alerts**.

+For a list and discussion of common Virtual Machines alert rules, see [Common alert rules](/azure/azure-monitor/vm/monitor-virtual-machine-alerts#common-alert-rules).

+## Other VM monitoring options

+Azure VMs has the following non-Azure Monitor monitoring options:

+### Boot diagnostics

+Boot diagnostics is a debugging feature for Azure VMs that allows you to diagnose VM boot failures by collecting serial log information and screenshots of a VM as it boots up. When you create a VM in the Azure portal, boot diagnostics is enabled by default. For more information, see [Azure boot diagnostics](boot-diagnostics.md).

+### Troubleshoot performance issues

+[The Performance Diagnostics tool](/troubleshoot/azure/virtual-machines/performance-diagnostics?toc=/azure/azure-monitor/toc.json) helps troubleshoot performance issues on Windows or Linux virtual machines by quickly diagnosing and providing insights on issues it currently finds on your machines. The tool doesn't analyze historical monitoring data you collect, but rather checks the current state of the machine for known issues, implementation of best practices, and complex problems that involve slow VM performance or high usage of CPU, disk space, or memory.

+## Related content

+- For a reference of the metrics, logs, and other important values for Virtual Machines, see [Virtual Machines monitoring data reference](monitor-vm-reference.md).

+- For general details about monitoring Azure resources, see [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource).

+- For guidance based on the five pillars of the Azure Well-Architected Framework, see [Best practices for monitoring virtual machines in Azure Monitor](/azure/azure-monitor/best-practices-vm).

+- To get started with VM insights, see [Overview of VM insights](/azure/azure-monitor/vm/vminsights-overview).

+- To learn how to collect and analyze VM host and client metrics and logs, see the training course [Monitor your Azure virtual machines with Azure Monitor](/training/modules/monitor-azure-vm-using-diagnostic-data).

+- For a complete guide to monitoring Azure and hybrid VMs, see the [Monitor virtual machines deployment guide](/azure/azure-monitor/vm/monitor-virtual-machine).

+| VPN Gateway (using Basic IPs) |At this time, it's not necessary to upgrade. When an upgrade is necessary, we'll update this decision path with migration information and send out a service health alert. |