-| gpt-4 (vision-preview) | | Sweden Central <br> Switzerland North<br>Australia East <br> West US |

-> [!NOTE]

-> As a temporary measure, GPT-4 Turbo with Vision is currently unavailable to new customers.

-| ```api-version``` | string | Required |The API version to use for this operation. This follows the YYYY-MM-DD format. |

-{"id":"chatcmpl-6v7mkQj980V1yBec6ETrKPRqFjNw9",

-"object":"chat.completion","created":1679072642,

-"model":"gpt-35-turbo",

-"usage":{"prompt_tokens":58,

-"completion_tokens":68,

-"total_tokens":126},

-"choices":[{"message":{"role":"assistant",

-"content":"Yes, other Azure AI services also support customer managed keys. Azure AI services offer multiple options for customers to manage keys, such as using Azure Key Vault, customer-managed keys in Azure Key Vault or customer-managed keys through Azure Storage service. This helps customers ensure that their data is secure and access to their services is controlled."},"finish_reason":"stop","index":0}]}

-Output formatting adjusted for ease of reading, actual output is a single block of text without line breaks.

-| ```temperature```| number | Optional | 1 | What sampling temperature to use, between 0 and 2. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic.\nWe generally recommend altering this or `top_p` but not both. |

-The following table provides an index of tools in prompt flow. If existing tools don't meet your requirements, you can [develop your own custom tool and make a tool package](https://microsoft.github.io/promptflow/how-to-guides/develop-a-tool/create-and-use-tool-package.html).

-> The open source Microsoft Entra pod-managed identity (preview) in Azure Kubernetes Service was deprecated on 10/24/2022, and the project archived in Sept. 2023. For more information, see the [deprecation notice](https://github.com/Azure/aad-pod-identity#-announcement). The AKS Managed add-on was deprecated in Sept. 2024.

-> The open source [Microsoft Entra pod-managed identity][entra-id-pod-managed-identity] (preview) in Azure Kubernetes Service was deprecated on 10/24/2022, and the project archived in Sept. 2023. For more information, see the [deprecation notice](https://github.com/Azure/aad-pod-identity#-announcement). The AKS Managed add-on was deprecated in Sept. 2024.

- <api name="API name" id="API id" calls="number" renewal-period="seconds" />

- <identityΓÇ»

- issuer-certificate-id="certificate identifier"ΓÇ»/>

-<validate-content unspecified-content-type-action="ignore | prevent | detect" max-size="size in bytes" size-exceeded-action="ignore | prevent | detect" errors-variable-name="variable name">

- <content type="content type string" validate-as="json | xml | soap" schema-id="schema id" schema-ref="#/local/reference/path" action="ignore | prevent | detect" allow-additional-properties="true | false" />

-App Service provides basic authentication for FTP and WebDeploy clients to connect to it by using [deployment credentials](deploy-configure-credentials.md). These APIs are great for browsing your siteΓÇÖs file system, uploading drivers and utilities, and deploying with MsBuild. However, enterprises often require more secure deployment methods than basic authentication, such as [Microsoft Entra ID](/entr)). Entra ID uses OAuth 2.0 token-based authorization and has many benefits and improvements that help mitigate the issues in basic authentication. For example, OAuth access tokens have a limited usable lifetime, and are specific to the applications and resources for which they're issued, so they can't be reused. Entra ID also lets you deploy from other Azure services using managed identities.

-When you disable basic authentication, deployment methods based on basic authentication stop working, such as FTP and local Git deployment. For alternate deployment methods, see [Authentication types by deployment methods in Azure App Service](deploy-authentication-types.md).

-<!-- Azure Pipelines with App Service deploy task (manual config) need the newer version hosted agent that supports vs2022.

-OIDC GitHub actions -->

-|Azure CLI |Microsoft Entra authentication | In Azure CLI, version 2.48.1 or higher, the following commands have been modified to use Microsoft Entra authentication if basic authentication is turned off for your web app or function app:<br/>- [az webapp up](/cli/azure/webapp#az-webapp-up)<br/>- [az webapp deploy](/cli/azure/webapp#az-webapp-deploy)<br/>- [az webapp deployment source config-zip](/cli/azure/webapp/deployment/source#az-webapp-deployment-source-config-zip)<br/>- [az webapp log deployment show](/cli/azure/webapp/log/deployment#az-webapp-log-deployment-show)<br/>- [az webapp log deployment list](/cli/azure/webapp/log/deployment#az-webapp-log-deployment-list)<br/>- [az webapp log download](/cli/azure/webapp/log#az-webapp-log-download)<br/>- [az webapp log tail](/cli/azure/webapp/log#az-webapp-log-tail)<br/>- [az webapp browse](/cli/azure/webapp#az-webapp-browse)<br/>- [az webapp create-remote-connection](/cli/azure/webapp#az-webapp-create-remote-connection)<br/>- [az webapp ssh](/cli/azure/webapp#az-webapp-ssh)<br/>- [az functionapp deploy](/cli/azure/functionapp#az-functionapp-deploy)<br/>- [az functionapp log deployment list](/cli/azure/functionapp/log/deployment#az-functionapp-log-deployment-list)<br/>- [az functionapp log deployment show](/cli/azure/functionapp/log/deployment#az-functionapp-log-deployment-show)<br/>- [az functionapp deployment source config-zip](/cli/azure/functionapp/deployment/source#az-functionapp-deployment-source-config-zip)<br/>For more information, see [az appservice](/cli/azure/appservice) and [az webapp](/cli/azure/webapp). |

-|Azure PowerShell |Microsoft Entra authentication | In Azure PowerShell, version 9.7.1 or above, Microsoft Entra authentication is available for App Service. For more information, see [PowerShell samples for Azure App Service](samples-powershell.md). |

-|SCM/Kudu/OneDeploy REST endpoint |Basic authentication, Microsoft Entra authentication |[Deploy files to App Service](deploy-zip.md) |

-|Kudu UI |Basic authentication, Microsoft Entra authentication |[Deploy files to App Service](deploy-zip.md)|

-|Visual Studio Code|Microsoft Entra authentication |[Quickstart: Deploy an ASP.NET web app](quickstart-dotnetcore.md)<br/> [Working with GitHub in VS Code](https://code.visualstudio.com/docs/sourcecontrol/github) |

-|GitHub with GitHub Actions |Publish profile, service principal, OpenID Connect |[Deploy to App Service using GitHub Actions](deploy-github-actions.md) |

-|GitHub with App Service build service as build engine|Publish profile |[Continuous deployment to Azure App Service](deploy-continuous-deployment.md) |

-|GitHub with Azure Pipelines as build engine|Publish profile, Azure DevOps service connection |[Deploy to App Service using Azure Pipelines](deploy-azure-pipelines.md) |

-|Azure Repos with App Service build service as build engine|Publish profile |[Continuous deployment to Azure App Service](deploy-continuous-deployment.md) |

-|Azure Repos with Azure Pipelines as build engine |Publish profile, Azure DevOps service connection |[Deploy to App Service using GitHub Actions](deploy-github-actions.md) |

-|Bitbucket |Publish profile |[Continuous deployment to Azure App Service](deploy-continuous-deployment.md) |

-|Local Git |Publish profile |[Local Git deployment to Azure App Service](deploy-local-git.md) |

-|External Git repository|Publish profile |[Setting up continuous deployment using manual steps](https://github.com/projectkudu/kudu/wiki/Continuous-deployment#setting-up-continuous-deployment-using-manual-steps) |

-|Run directly from an uploaded ZIP file |Microsoft Entra authentication |[Run your app in Azure App Service directly from a ZIP package](deploy-run-package.md) |

-|Run directly from external URL |Storage account key, managed identity |[Run from external URL instead](deploy-run-package.md#run-from-external-url-instead) |

-|Azure Web app plugin for Maven (Java) |Microsoft Entra authentication |[Quickstart: Create a Java app on Azure App Service](quickstart-java.md)|

-|Azure WebApp Plugin for Gradle (Java) |Microsoft Entra authentication |[Configure a Java app for Azure App Service](configure-language-java.md)|

-|Webhooks |Publish profile |[Web hooks](https://github.com/projectkudu/kudu/wiki/Web-hooks) |

-|Azure Migrate App Service discovery/assessment/migration |Microsoft Entra authentication |[Tutorial: Assess ASP.NET web apps for migration to Azure App Service](../migrate/tutorial-assess-webapps.md)<br/>[Modernize ASP.NET web apps to Azure App Service code](../migrate/tutorial-modernize-asp-net-appservice-code.md) |

-A deployment source is the location of your application code. For production apps, the deployment source is usually a repository hosted by version control software such as [GitHub, BitBucket, or Azure Repos](deploy-continuous-deployment.md). For development and test scenarios, the deployment source may be [a project on your local machine](deploy-local-git.md). App Service also supports [OneDrive and Dropbox folders](deploy-content-sync.md) as deployment sources. While cloud folders can make it easy to get started with App Service, it's not typically recommended to use this source for enterprise-level production applications.

-> The **Development Center (Classic)** page in the Azure portal, which is the old deployment experience, will be deprecated in March, 2021. This change will not affect any existing deployment settings in your app, and you can continue to manage app deployment in the **Deployment Center** page.

-description: Learn how to deploy your app to Azure App Service via content sync from a cloud folder, including OneDrive or Dropbox.

-# Sync content from a cloud folder to Azure App Service

-This article shows you how to sync your content to [Azure App Service](./overview.md) from Dropbox and OneDrive.

-With the content sync approach, your work with your app code and content in a designated cloud folder to make sure it's in a ready-to-deploy state, and then sync to App Service with the click of a button.

-Because of underlying differences in the APIs, **OneDrive for Business** is not supported at this time.

-> [!NOTE]

-> The **Development Center (Classic)** page in the Azure portal, which is the old deployment experience, will be deprecated in March, 2021. This change will not affect any existing deployment settings in your app, and you can continue to manage app deployment in the **Deployment Center** page.

-## Enable content sync deployment

-1. In the [Azure portal](https://portal.azure.com), navigate to the management page for your App Service app.

-1. From the left menu, click **Deployment Center** > **Settings**.

-1. In **Source**, select **OneDrive** or **Dropbox**.

-1. Click **Authorize** and follow the authorization prompts.

- 

- You only need to authorize with OneDrive or Dropbox once for your Azure account. To authorize a different OneDrive or Dropbox account for an app, click **Change account**.

-1. In **Folder**, select the folder to synchronize. This folder is created under the following designated content path in OneDrive or Dropbox.

-

- * **OneDrive**: `Apps\Azure Web Apps`

- * **Dropbox**: `Apps\Azure`

-

-1. Click **Save**.

-## Synchronize content

-# [Azure portal](#tab/portal)

-1. In the [Azure portal](https://portal.azure.com), navigate to the management page for your App Service app.

-1. From the left menu, click **Deployment Center** > **Redeploy/Sync**.

- 

-

-1. Click **OK** to confirm the sync.

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

-Start a sync by running the following command and replacing \<group-name> and \<app-name>:

-```azurecli-interactive

-az webapp deployment source sync --resource-group <group-name> --name <app-name>

-```

-# [Azure PowerShell](#tab/powershell)

-Start a sync by running the following command and replacing \<group-name> and \<app-name>:

-```azurepowershell-interactive

-Invoke-AzureRmResourceAction -ResourceGroupName <group-name> -ResourceType Microsoft.Web/sites -ResourceName <app-name> -Action sync -ApiVersion 2019-08-01 -Force ΓÇôVerbose

-```

-## Disable content sync deployment

-1. In the [Azure portal](https://portal.azure.com), navigate to the management page for your App Service app.

-1. From the left menu, click **Deployment Center** > **Settings** > **Disconnect**.

- 

-## OneDrive and Dropbox integration retirements

-On September 30th, 2023 the integrations for Microsoft OneDrive and Dropbox for Azure App Service and Azure Functions will be retired. If you are using OneDrive or Dropbox, you should [disable content sync deployments](#disable-content-sync-deployment) from OneDrive and Dropbox. Then, you can set up deployments from any of the following alternatives

-## Next steps

-> [!div class="nextstepaction"]

-> [Deploy from local Git repo](deploy-local-git.md)

-> [!NOTE]

-> The **Development Center (Classic)** page in the Azure portal, an earlier version of the deployment functionality, was deprecated in March 2021. This change doesn't affect existing deployment settings in your app, and you can continue to manage app deployment from the **Deployment Center** page in the portal.

-4. [GitHub Actions](#how-does-the-github-actions-build-provider-work) is the default build provider. To change the provider, select **Change provider** > **App Service Build Service** (Kudu) > **OK**.

- > [!NOTE]

- > To use Azure Pipelines as the build provider for your App Service app, configure CI/CD directly from Azure Pipelines. Don't configure it in App Service. The **Azure Pipelines** option just points you in the right direction.

-1. After you authorize your Azure account with GitHub, select the **Organization**, **Repository**, and **Branch** to configure CI/CD for.

-1. (Preview) Under **Authentication type**, select **User-assigned identity** for better security. For more information, see [frequently asked questions]().

-1. When **GitHub Actions** is selected as the build provider, you can select the workflow file you want by using the **Runtime stack** and **Version** dropdown lists. Azure commits this workflow file into your selected GitHub repository to handle build and deploy tasks. To see the file before saving your changes, select **Preview file**.

- > App Service detects the [language stack setting](configure-common.md#configure-language-stack-settings) of your app and selects the most appropriate workflow template. If you choose a different template, it might deploy an app that doesn't run properly. For more information, see [How the GitHub Actions build provider works](#how-does-the-github-actions-build-provider-work).

-The Bitbucket integration uses the App Service Build Services (Kudu) for build automation.

-

-

- > [!NOTE]

- > Azure Repos is supported as a deployment source for Windows apps.

- >

-4. App Service Build Service (Kudu) is the default build provider.

- > To use Azure Pipelines as the build provider for your App Service app, configure CI/CD directly from Azure Pipelines. Don't configure it in App Service. The **Azure Pipelines** option just points you in the right direction.

-## Frequently asked questions

-#### How does the GitHub Actions build provider work?

-The GitHub Actions build provider is an option for [CI/CD from GitHub](#configure-the-deployment-source). It completes these actions to set up CI/CD:

-#### How do I configure continuous deployment without basic authentication?

-To configure continuous deployment [without basic authentication](configure-basic-auth-disable.md), try using GitHub Actions with the **user-assigned identity** option.

-When you select **user-assigned identity** under the **GitHub Actions** source, Azure creates a [user-managed identity](/en-us/entra/identity/managed-identities-azure-resources/overview#managed-identity-types) for you and [federates it with GitHub as an authorized client](/entra/workload-id/workload-identity-federation-create-trust-user-assigned-managed-identity?pivots=identity-wif-mi-methods-azp). This user-managed identity isn't shown in the **Identities** page for your app.

-This automatically created user-managed identity should be used only for the GitHub Actions deployment. Using it for other configurations isn't supported.

-#### I see "You do not have sufficient permissions on this app to assign role-based access to a managed identity and configure federated credentials." when I select the user-assigned identity option with GitHub Actions.

-To use the **user-assigned identity** option for your GitHub Actions deployment, you need the `Microsoft.Authorization/roleAssignments/write` permission on your app. By default, the **User Access Administrator** role and **Owner** role have this permission already, but the **Contributor** role doesn't.

-#### How do I deploy from other repositories

-For Windows apps, you can manually configure continuous deployment from a cloud Git or Mercurial repository that the portal doesn't directly support, like [GitLab](https://gitlab.com/). You do that by selecting **External Git** in the **Source** dropdown list. For more information, see [Set up continuous deployment using manual steps](https://github.com/projectkudu/kudu/wiki/Continuous-deployment#setting-up-continuous-deployment-using-manual-steps).

-* [Deploy from Azure Pipelines to Azure App Services](/azure/devops/pipelines/apps/cd/deploy-webdeploy-webapps)

-* [Investigate common problems with continuous deployment](https://github.com/projectkudu/kudu/wiki/Investigating-continuous-deployment)

-* [Project Kudu](https://github.com/projectkudu/kudu/wiki)

-> The **Development Center (Classic)** page in the Azure portal, which is the old deployment experience, will be deprecated in March, 2021. This change will not affect any existing deployment settings in your app, and you can continue to manage app deployment in the **Deployment Center** page.

-2. To disable unencrypted FTP, select **FTPS Only** in **FTP state**. To disable both FTP and FTPS entirely, select **Disabled**. When finished, click **Save**. If using **FTPS Only**, you must enforce TLS 1.2 or higher by navigating to the **TLS/SSL settings** blade of your web app. TLS 1.0 and 1.1 are not supported with **FTPS Only**.

-Check that you've entered the correct [hostname](#get-ftps-endpoint) and [credentials](#get-deployment-credentials). Check also that the following FTP ports on your machine are not blocked by a firewall:

-One thing to be aware that can affect your connection success is the URL used, this will depend on the Client Application used.

-The portal will have just the URL as "ftps://" and you might need to change this.

- Make sure to not mix both, such as attempting to connect to "ftps://" and using port 21, as it will fail to connect, even if you wish to do Explicit encryption.

- The reason for this is due to an Explicit connection starting as a plain FTP connection before the AUTH method.

-Let us say you take over owning an app and you wish to find out how the Azure App Service was deployed so you can make changes and deploy them. You can determine how an Azure App Service was deployed by checking the application settings. If the app was deployed using an external package URL, you will see the WEBSITE_RUN_FROM_PACKAGE setting in the application settings with a URL value. Or if it was deployed using zip deploy, you will see the WEBSITE_RUN_FROM_PACKAGE setting with a value of 1. If the app was deployed using Azure DevOps, you will see the deployment history in the Azure DevOps portal. If Azure Functions Core Tools was used, you will see the deployment history in the Azure portal.

- - .NET: [Create an ASP.NET Core web app in Azure](quickstart-dotnetcore.md)

- - ASP.NET: [Create an ASP.NET Framework web app in Azure](./quickstart-dotnetcore.md?tabs=netframework48)

- - JavaScript: [Create a Node.js web app in Azure App Service](quickstart-nodejs.md)

- - Java: [Create a Java app on Azure App Service](quickstart-java.md)

- - Python: [Create a Python app in Azure App Service](quickstart-python.md)

-## Workflow file overview

-A workflow is defined by a YAML (.yml) file in the `/.github/workflows/` path in your repository. This definition contains the various steps and parameters that make up the workflow.

-The file has three sections:

-|Section |Tasks |

-|||

-|**Authentication** | 1. Define a service principal or publish profile. <br /> 2. Create a GitHub secret. |

-|**Build** | 1. Set up the environment. <br /> 2. Build the web app. |

-|**Deploy** | 1. Deploy the web app. |

-## Use the Deployment Center

-You can quickly get started with GitHub Actions by using the App Service Deployment Center. This turn-key method automatically generates a workflow file based on your application stack and commits it to your GitHub repository in the correct directory. For more information, see [Continuous deployment to Azure App Service](deploy-continuous-deployment.md).

-## Set up a workflow manually

-You can also deploy a workflow without using the Deployment Center. To do so, you need to first generate deployment credentials.

-## Generate deployment credentials

-OpenID Connect is an authentication method that uses short-lived tokens. Setting up [OpenID Connect with GitHub Actions](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect) is more complex process that offers hardened security.

-## Configure the GitHub secret

-To use [app-level credentials](#generate-deployment-credentials), paste the contents of the downloaded publish profile file into the secret's value field. Name the secret `AZURE_WEBAPP_PUBLISH_PROFILE`.

-When you configure your GitHub workflow, you use the `AZURE_WEBAPP_PUBLISH_PROFILE` in the deploy Azure Web App action. For example:

-To use [user-level credentials](#generate-deployment-credentials), paste the entire JSON output from the Azure CLI command into the secret's value field. Give the secret the name `AZURE_CREDENTIALS`.

-When you configure the workflow file later, you use the secret for the input `creds` of the Azure Login action. For example:

-You need to provide your application's **Client ID**, **Tenant ID** and **Subscription ID** to the login action. These values can either be provided directly in the workflow or can be stored in GitHub secrets and referenced in your workflow. Saving the values as GitHub secrets is the more secure option.

-## Set up the environment

-Setting up the environment can be done using one of the setup actions.

-|**Language** |**Setup Action** |

-|||

-|**.NET** | `actions/setup-dotnet` |

-|**ASP.NET** | `actions/setup-dotnet` |

-|**Java** | `actions/setup-java` |

-|**JavaScript** | `actions/setup-node` |

-|**Python** | `actions/setup-python` |

-The following examples show how to set up the environment for the different supported languages:

-**.NET**

-```yaml

- - name: Setup Dotnet 6.0.x

- uses: actions/setup-dotnet@v3

- with:

- dotnet-version: '6.0.x'

-```

-**ASP.NET**

-```yaml

- - name: Install Nuget

- uses: nuget/setup-nuget@v1

- with:

- nuget-version: ${{ env.NUGET_VERSION}}

-```

-**Java**

-```yaml

- - name: Setup Java 1.8.x

- uses: actions/setup-java@v3

- with:

- # If your pom.xml <maven.compiler.source> version is not in 1.8.x,

- # change the Java version to match the version in pom.xml <maven.compiler.source>

- java-version: '1.8.x'

-```

-**JavaScript**

-```yaml

-env:

- NODE_VERSION: '18.x' # set this to the node version to use

-jobs:

- build-and-deploy:

- name: Build and Deploy

- runs-on: ubuntu-latest

- steps:

- - uses: actions/checkout@main

- - name: Use Node.js ${{ env.NODE_VERSION }}

- uses: actions/setup-node@v4

- with:

- node-version: ${{ env.NODE_VERSION }}

-```

-**Python**

-```yaml

- - name: Setup Python 3.x

- uses: actions/setup-python@v4

- with:

- python-version: 3.x

-```

-## Build the web app

-The process of building a web app and deploying to Azure App Service changes depending on the language.

-For all languages, you can set the web app root directory with `working-directory`.

-**.NET**

-The environment variable `AZURE_WEBAPP_PACKAGE_PATH` sets the path to your web app project.

-```yaml

- run: |

- dotnet restore

- dotnet build --configuration Release

- dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'

-```

-**ASP.NET**

-You can restore NuGet dependencies and run msbuild with `run`.

-```yaml

- run: nuget restore

- uses: microsoft/setup-msbuild@v1.0.2

- run: msbuild .\SampleWebApplication.sln

-```

-**Java**

-```yaml

- run: mvn package --file pom.xml

-```

-**JavaScript**

-For Node.js, you can set `working-directory` or change for npm directory in `pushd`.

-```yaml

- run: |

- npm install

- npm run build --if-present

- npm run test --if-present

- working-directory: my-app-folder # set to the folder with your app if it is not the root directory

-```

-**Python**

-```yaml

- run: |

- python -m pip install --upgrade pip

- pip install -r requirements.txt

-```

-## Deploy to App Service

-To deploy your code to an App Service app, use the `azure/webapps-deploy@v2` action. This action has four parameters:

-| **Parameter** | **Explanation** |

-|||

-| **app-name** | (Required) Name of the App Service app |

-| **publish-profile** | (Optional) Publish profile file contents with Web Deploy secrets |

-| **package** | (Optional) Path to package or folder. The path can include *.zip, *.war, *.jar, or a folder to deploy |

-| **slot-name** | (Optional) Enter an existing slot other than the production [slot](deploy-staging-slots.md) |

-### .NET Core

-Build and deploy a .NET Core app to Azure using an Azure publish profile. The `publish-profile` input references the `AZURE_WEBAPP_PUBLISH_PROFILE` secret that you created earlier.

-```yaml

-name: .NET Core CI

-on: [push]

-env:

- AZURE_WEBAPP_NAME: my-app-name # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

- DOTNET_VERSION: '6.0.x' # set this to the dot net version to use

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- # Checkout the repo

- - uses: actions/checkout@main

-

- # Setup .NET Core SDK

- - name: Setup .NET Core

- uses: actions/setup-dotnet@v3

- with:

- dotnet-version: ${{ env.DOTNET_VERSION }}

-

- # Run dotnet build and publish

- - name: dotnet build and publish

- run: |

- dotnet restore

- dotnet build --configuration Release

- dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'

-

- # Deploy to Azure Web apps

- - name: 'Run Azure webapp deploy action using publish profile credentials'

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name

- publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }} # Define secret variable in repository settings as per action documentation

- package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'

-```

-### ASP.NET

-Build and deploy an ASP.NET MVC app that uses NuGet and `publish-profile` for authentication.

-```yaml

-name: Deploy ASP.NET MVC App deploy to Azure Web App

-on: [push]

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

- NUGET_VERSION: '5.3.x' # set this to the dot net version to use

-jobs:

- build-and-deploy:

- runs-on: windows-latest

- steps:

- - uses: actions/checkout@main

-

- - name: Install Nuget

- uses: nuget/setup-nuget@v1

- with:

- nuget-version: ${{ env.NUGET_VERSION}}

- - name: NuGet to restore dependencies as well as project-specific tools that are specified in the project file

- run: nuget restore

-

- - name: Add msbuild to PATH

- uses: microsoft/setup-msbuild@v1.0.2

- - name: Run MSBuild

- run: msbuild .\SampleWebApplication.sln

-

- - name: 'Run Azure webapp deploy action using publish profile credentials'

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name

- publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }} # Define secret variable in repository settings as per action documentation

- package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/SampleWebApplication/'

-```

-### Java

-Build and deploy a Java Spring app to Azure using an Azure publish profile. The `publish-profile` input references the `AZURE_WEBAPP_PUBLISH_PROFILE` secret that you created earlier.

-```yaml

-name: Java CI with Maven

-on: [push]

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- - uses: actions/checkout@v4

- - name: Set up JDK 1.8

- uses: actions/setup-java@v3

- with:

- java-version: 1.8

- - name: Build with Maven

- run: mvn -B package --file pom.xml

- working-directory: my-app-path

- - name: Azure WebApp

- uses: Azure/webapps-deploy@v2

- with:

- app-name: my-app-name

- publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

- package: my/target/*.jar

-```

-To deploy a `war` instead of a `jar`, change the `package` value.

-```yaml

- - name: Azure WebApp

- uses: Azure/webapps-deploy@v2

- with:

- app-name: my-app-name

- publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

- package: my/target/*.war

-```

-### JavaScript

-Build and deploy a Node.js app to Azure using the app's publish profile. The `publish-profile` input references the `AZURE_WEBAPP_PUBLISH_PROFILE` secret that you created earlier.

-```yaml

-# File: .github/workflows/workflow.yml

-name: JavaScript CI

-on: [push]

-env:

- AZURE_WEBAPP_NAME: my-app-name # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: 'my-app-path' # set this to the path to your web app project, defaults to the repository root

- NODE_VERSION: '18.x' # set this to the node version to use

-jobs:

- build-and-deploy:

- name: Build and Deploy

- runs-on: ubuntu-latest

- steps:

- - uses: actions/checkout@main

- - name: Use Node.js ${{ env.NODE_VERSION }}

- uses: actions/setup-node@v4

- with:

- node-version: ${{ env.NODE_VERSION }}

- - name: npm install, build, and test

- run: |

- # Build and test the project, then

- # deploy to Azure Web App.

- npm install

- npm run build --if-present

- npm run test --if-present

- working-directory: my-app-path

- - name: 'Deploy to Azure WebApp'

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }}

- publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

- package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

-```

-### Python

-Build and deploy a Python app to Azure using the app's publish profile. Note how the `publish-profile` input references the `AZURE_WEBAPP_PUBLISH_PROFILE` secret that you created earlier.

-```yaml

-name: Python CI

-on:

- [push]

-env:

- AZURE_WEBAPP_NAME: my-web-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- - uses: actions/checkout@v4

- - name: Set up Python 3.x

- uses: actions/setup-python@v4

- with:

- python-version: 3.x

- - name: Install dependencies

- run: |

- python -m pip install --upgrade pip

- pip install -r requirements.txt

- - name: Building web app

- uses: azure/appservice-build@v2

- - name: Deploy web App using GH Action azure/webapps-deploy

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }}

- publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}

- package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

-```

-### .NET Core

-Build and deploy a .NET Core app to Azure using an Azure service principal. Note how the `creds` input references the `AZURE_CREDENTIALS` secret that you created earlier.

-```yaml

-name: .NET Core

-on: [push]

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

- DOTNET_VERSION: '6.0.x' # set this to the dot net version to use

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- # Checkout the repo

- - uses: actions/checkout@main

- - uses: azure/login@v1

- with:

- creds: ${{ secrets.AZURE_CREDENTIALS }}

-

- # Setup .NET Core SDK

- - name: Setup .NET Core

- uses: actions/setup-dotnet@v3

- with:

- dotnet-version: ${{ env.DOTNET_VERSION }}

-

- # Run dotnet build and publish

- - name: dotnet build and publish

- run: |

- dotnet restore

- dotnet build --configuration Release

- dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'

-

- # Deploy to Azure Web apps

- - name: 'Run Azure webapp deploy action using Azure Credentials'

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name

- package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'

-

- - name: logout

- run: |

- az logout

-```

-### ASP.NET

-Build and deploy a ASP.NET MVC app to Azure using an Azure service principal. Note how the `creds` input references the `AZURE_CREDENTIALS` secret that you created earlier.

-```yaml

-name: Deploy ASP.NET MVC App deploy to Azure Web App

-on: [push]

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

- NUGET_VERSION: '5.3.x' # set this to the dot net version to use

-jobs:

- build-and-deploy:

- runs-on: windows-latest

- steps:

- # checkout the repo

- - uses: actions/checkout@main

-

- - uses: azure/login@v1

- with:

- creds: ${{ secrets.AZURE_CREDENTIALS }}

- - name: Install Nuget

- uses: nuget/setup-nuget@v1

- with:

- nuget-version: ${{ env.NUGET_VERSION}}

- - name: NuGet to restore dependencies as well as project-specific tools that are specified in the project file

- run: nuget restore

-

- - name: Add msbuild to PATH

- uses: microsoft/setup-msbuild@v1.0.2

- - name: Run MSBuild

- run: msbuild .\SampleWebApplication.sln

-

- - name: 'Run Azure webapp deploy action using Azure Credentials'

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name

- package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/SampleWebApplication/'

-

- # Azure logout

- - name: logout

- run: |

- az logout

-```

-### Java

-Build and deploy a Java Spring app to Azure using an Azure service principal. Note how the `creds` input references the `AZURE_CREDENTIALS` secret that you created earlier.

-```yaml

-name: Java CI with Maven

-on: [push]

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- - uses: actions/checkout@v4

- - uses: azure/login@v1

- with:

- creds: ${{ secrets.AZURE_CREDENTIALS }}

- - name: Set up JDK 1.8

- uses: actions/setup-java@v3

- with:

- java-version: 1.8

- - name: Build with Maven

- run: mvn -B package --file pom.xml

- working-directory: complete

- - name: Azure WebApp

- uses: Azure/webapps-deploy@v2

- with:

- app-name: my-app-name

- package: my/target/*.jar

- # Azure logout

- - name: logout

- run: |

- az logout

-```

-### JavaScript

-Build and deploy a Node.js app to Azure using an Azure service principal. Note how the `creds` input references the `AZURE_CREDENTIALS` secret that you created earlier.

-```yaml

-name: JavaScript CI

-on: [push]

-name: Node.js

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: 'my-app-path' # set this to the path to your web app project, defaults to the repository root

- NODE_VERSION: '18.x' # set this to the node version to use

-jobs:

- build-and-deploy:

- runs-on: ubuntu-latest

- steps:

- # checkout the repo

- - name: 'Checkout GitHub Action'

- uses: actions/checkout@main

-

- - uses: azure/login@v1

- with:

- creds: ${{ secrets.AZURE_CREDENTIALS }}

-

- - name: Setup Node ${{ env.NODE_VERSION }}

- uses: actions/setup-node@v4

- with:

- node-version: ${{ env.NODE_VERSION }}

-

- - name: 'npm install, build, and test'

- run: |

- npm install

- npm run build --if-present

- npm run test --if-present

- working-directory: my-app-path

-

- # deploy web app using Azure credentials

- - uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }}

- package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

- # Azure logout

- - name: logout

- run: |

- az logout

-```

-### Python

-Build and deploy a Python app to Azure using an Azure service principal. Note how the `creds` input references the `AZURE_CREDENTIALS` secret that you created earlier.

-```yaml

-name: Python application

-on:

- [push]

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- - uses: actions/checkout@v4

-

- - uses: azure/login@v1

- with:

- creds: ${{ secrets.AZURE_CREDENTIALS }}

- - name: Set up Python 3.x

- uses: actions/setup-python@v4

- with:

- python-version: 3.x

- - name: Install dependencies

- run: |

- python -m pip install --upgrade pip

- pip install -r requirements.txt

- - name: Deploy web App using GH Action azure/webapps-deploy

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }}

- package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

- - name: logout

- run: |

- az logout

-```

-### .NET Core

-Build and deploy a .NET Core app to Azure using an Azure service principal. The example uses GitHub secrets for the `client-id`, `tenant-id`, and `subscription-id` values. You can also pass these values directly in the login action.

-```yaml

-name: .NET Core

-on: [push]

-permissions:

- id-token: write

- contents: read

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

- DOTNET_VERSION: '6.0.x' # set this to the dot net version to use

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- # Checkout the repo

- - uses: actions/checkout@main

- - uses: azure/login@v1

- with:

- client-id: ${{ secrets.AZURE_CLIENT_ID }}

- tenant-id: ${{ secrets.AZURE_TENANT_ID }}

- subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

-

- # Setup .NET Core SDK

- - name: Setup .NET Core

- uses: actions/setup-dotnet@v3

- with:

- dotnet-version: ${{ env.DOTNET_VERSION }}

-

- # Run dotnet build and publish

- - name: dotnet build and publish

- run: |

- dotnet restore

- dotnet build --configuration Release

- dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'

-

- # Deploy to Azure Web apps

- - name: 'Run Azure webapp deploy action using publish profile credentials'

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name

- package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'

-

- - name: logout

- run: |

- az logout

-```

-### ASP.NET

-Build and deploy a ASP.NET MVC app to Azure using an Azure service principal. The example uses GitHub secrets for the `client-id`, `tenant-id`, and `subscription-id` values. You can also pass these values directly in the login action.

-```yaml

-name: Deploy ASP.NET MVC App deploy to Azure Web App

-on: [push]

-permissions:

- id-token: write

- contents: read

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

- NUGET_VERSION: '5.3.x' # set this to the dot net version to use

-jobs:

- build-and-deploy:

- runs-on: windows-latest

- steps:

- # checkout the repo

- - uses: actions/checkout@main

-

- - uses: azure/login@v1

- with:

- client-id: ${{ secrets.AZURE_CLIENT_ID }}

- tenant-id: ${{ secrets.AZURE_TENANT_ID }}

- subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- - name: Install Nuget

- uses: nuget/setup-nuget@v1

- with:

- nuget-version: ${{ env.NUGET_VERSION}}

- - name: NuGet to restore dependencies as well as project-specific tools that are specified in the project file

- run: nuget restore

-

- - name: Add msbuild to PATH

- uses: microsoft/setup-msbuild@v1.0.2

- - name: Run MSBuild

- run: msbuild .\SampleWebApplication.sln

-

- - name: 'Run Azure webapp deploy action using publish profile credentials'

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name

- package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/SampleWebApplication/'

-

- # Azure logout

- - name: logout

- run: |

- az logout

-```

-### Java

-Build and deploy a Java Spring app to Azure using an Azure service principal. The example uses GitHub secrets for the `client-id`, `tenant-id`, and `subscription-id` values. You can also pass these values directly in the login action.

-```yaml

-name: Java CI with Maven

-on: [push]

-permissions:

- id-token: write

- contents: read

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- - uses: actions/checkout@v4

- - uses: azure/login@v1

- with:

- client-id: ${{ secrets.AZURE_CLIENT_ID }}

- tenant-id: ${{ secrets.AZURE_TENANT_ID }}

- subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- - name: Set up JDK 1.8

- uses: actions/setup-java@v3

- with:

- java-version: 1.8

- - name: Build with Maven

- run: mvn -B package --file pom.xml

- working-directory: complete

- - name: Azure WebApp

- uses: Azure/webapps-deploy@v2

- with:

- app-name: my-app-name

- package: my/target/*.jar

- # Azure logout

- - name: logout

- run: |

- az logout

-```

-### JavaScript

-Build and deploy a Node.js app to Azure using an Azure service principal. The example uses GitHub secrets for the `client-id`, `tenant-id`, and `subscription-id` values. You can also pass these values directly in the login action.

-```yaml

-name: JavaScript CI

-on: [push]

-permissions:

- id-token: write

- contents: read

-name: Node.js

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: 'my-app-path' # set this to the path to your web app project, defaults to the repository root

- NODE_VERSION: '18.x' # set this to the node version to use

-jobs:

- build-and-deploy:

- runs-on: ubuntu-latest

- steps:

- # checkout the repo

- - name: 'Checkout GitHub Action'

- uses: actions/checkout@main

-

- - uses: azure/login@v1

- with:

- client-id: ${{ secrets.AZURE_CLIENT_ID }}

- tenant-id: ${{ secrets.AZURE_TENANT_ID }}

- subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

-

- - name: Setup Node ${{ env.NODE_VERSION }}

- uses: actions/setup-node@v4

- with:

- node-version: ${{ env.NODE_VERSION }}

-

- - name: 'npm install, build, and test'

- run: |

- npm install

- npm run build --if-present

- npm run test --if-present

- working-directory: my-app-path

-

- # deploy web app using Azure credentials

- - uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }}

- package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

- # Azure logout

- - name: logout

- run: |

- az logout

-```

-### Python

-Build and deploy a Python app to Azure using an Azure service principal. The example uses GitHub secrets for the `client-id`, `tenant-id`, and `subscription-id` values. You can also pass these values directly in the login action.

-```yaml

-name: Python application

-on:

- [push]

-permissions:

- id-token: write

- contents: read

-env:

- AZURE_WEBAPP_NAME: my-app # set this to your application's name

- AZURE_WEBAPP_PACKAGE_PATH: '.' # set this to the path to your web app project, defaults to the repository root

-jobs:

- build:

- runs-on: ubuntu-latest

- steps:

- - uses: actions/checkout@v4

-

- - uses: azure/login@v1

- with:

- client-id: ${{ secrets.AZURE_CLIENT_ID }}

- tenant-id: ${{ secrets.AZURE_TENANT_ID }}

- subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

- - name: Set up Python 3.x

- uses: actions/setup-python@v4

- with:

- python-version: 3.x

- - name: Install dependencies

- run: |

- python -m pip install --upgrade pip

- pip install -r requirements.txt

- - name: Deploy web App using GH Action azure/webapps-deploy

- uses: azure/webapps-deploy@v2

- with:

- app-name: ${{ env.AZURE_WEBAPP_NAME }}

- package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}

- - name: logout

- run: |

- az logout

-```

-If you haven't created an app yet, see [Create a Git enabled app](#create-a-git-enabled-app) instead.

-1. From the left menu, select **Deployment Center** > **Settings**. Select **Local Git** in **Source**, then click **Save**.

-1. Review the output. You may see runtime-specific automation, such as MSBuild for ASP.NET, `npm install` for Node.js, and `pip install` for Python.

- You can also change the `DEPLOYMENT_BRANCH` app setting in the Azure Portal, by selecting **Configuration** under **Settings** and adding a new Application Setting with a name of `DEPLOYMENT_BRANCH` and value of `main`.

-You may see the following common error messages when you use Git to publish to an App Service app in Azure:

-|`Couldn't resolve host 'hostname'`|The address information for the 'azure' remote is incorrect.|Use the `git remote -v` command to list all remotes, along with the associated URL. Verify that the URL for the 'azure' remote is correct. If needed, remove and recreate this remote using the correct URL.|

-|`Error - Changes committed to remote repository but deployment to website failed.`|You pushed a local branch that doesn't match the app deployment branch on 'azure'.|Verify that current branch is `master`. To change the default branch, use `DEPLOYMENT_BRANCH` application setting (see [Change deployment branch](#change-deployment-branch)). |

-|`src refspec [branchname] does not match any.`|You tried to push to a branch other than main on the 'azure' remote.|Run `git push` again, specifying the main branch: `git push azure main`.|

-## Additional resources

-For more information, see [Kudu documentation](https://github.com/projectkudu/kudu/wiki/Deploying-from-a-zip-file).

-> Files in the ZIP package are copied only if their timestamps don't match what is already deployed. Generating a zip using a build process that caches outputs can result in faster deployments. See [Deploying from a zip file or url](https://github.com/projectkudu/kudu/wiki/Deploying-from-a-zip-file-or-url), for more information.

-The following example uses the `--src-url` parameter to specify the URL of an Azure Storage account that the site should pull the ZIP from.

-```azurecli-interactive

-az webapp deploy --resource-group <group-name> --name <app-name> --src-url "https://storagesample.blob.core.windows.net/sample-container/myapp.zip?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3

-```

-The following example uses [Publish-AzWebapp](/powershell/module/az.websites/publish-azwebapp) to upload the ZIP package. Replace the placeholders `<group-name>`, `<app-name>`, and `<zip-package-path>`.

-```powershell

-The following example uses the cURL tool to deploy a ZIP package. Replace the placeholders `<username>`, `<password>`, `<zip-package-path>`, and `<app-name>`. Use the [deployment credentials](deploy-configure-credentials.md) for authentication.

-curl -X POST \

- -H "Content-Type: application/octet-stream" \

- -u '<username>:<password>' \

- -T "<zip-package-path>" \

- "https://<app-name>.scm.azurewebsites.net/api/zipdeploy"

-```

-The following example uses the `packageUri` parameter to specify the URL of an Azure Storage account that the web app should pull the ZIP from.

-```bash

-curl -X PUT \

- -H "Content-Type: application/json" \

- -d '{"packageUri": "https://storagesample.blob.core.windows.net/sample-container/myapp.zip?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3"}' \

- "https://<app-name>.scm.azurewebsites.net/api/zipdeploy"

-# [Kudu UI](#tab/kudu-ui)

-In the browser, navigate to `https://<app_name>.scm.azurewebsites.net/ZipDeployUI`.

-Upload the ZIP package you created in [Create a project ZIP package](#create-a-project-zip-package) by dragging it to the file explorer area on the web page.

-When deployment is in progress, an icon in the top right corner shows you the progress in percentage. The page also shows verbose messages for the operation below the explorer area. When it is finished, the last deployment message should say `Deployment successful`.

-The above endpoint does not work for Linux App Services at this time. Consider using FTP or the [ZIP deploy API](./faq-app-service-linux.yml) instead.

-> [!NOTE]

-> To deploy a ZIP package in an [ARM template](), upload the ZIP package to an internet-accessible location, then add a `onedeploy` resource like the following JSON. Replace the placeholders `<app-name>` and `<zip-package-uri>`.

->

-> ```ARM template

-> {

-> "type": "Microsoft.Web/sites/extensions",

-> "apiVersion": "2021-03-01",

-> "name": "onedeploy",

-> "dependsOn": [

-> "[resourceId('Microsoft.Web/Sites', <app-name>')]"

-> ],

-> "properties": {

-> "packageUri": "<zip-package-uri>",

-> "type":"zip"

-> }

-> }

-> ```

->

-> The \<zip-package-uri> can be a public endpoint, but it's best to use blob storage with a SAS key to protect it. For more information, see [Microsoft.Web sites/extensions 'onedeploy' 2021-03-01](/azure/templates/microsoft.web/2021-03-01/sites/extensions-onedeploy?pivots=deployment-language-arm-template).

->

->

-## Enable build automation for ZIP deploy

-The deployment process used by the steps here places the package on the app's content share with the right naming convention and directory structure (see [Kudu publish API reference](#kudu-publish-api-reference)), and it's the recommended approach. If you deploy WAR/JAR/EAR packages using [FTP](deploy-ftp.md) or WebDeploy instead, you may see unkown failures due to mistakes in the naming or structure.

-The following example uses the `--src-url` parameter to specify the URL of an Azure Storage account that the web app should pull the WAR from.

-```azurecli-interactive

-az webapp deploy --resource-group <group-name> --name <app-name> --src-url "https://storagesample.blob.core.windows.net/sample-container/myapp.war?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3 --type war

-```

-The following example uses the cURL tool to deploy a .war, .jar, or .ear file. Replace the placeholders `<username>`, `<file-path>`, `<app-name>`, and `<package-type>` (`war`, `jar`, or `ear`, accordingly). When prompted by cURL, type in the [deployment password](deploy-configure-credentials.md).

-curl -X POST -u <username> -T @"<file-path>" https://<app-name>.scm.azurewebsites.net/api/publish?type=<package-type>

-```

-The following example uses the `packageUri` parameter to specify the URL of an Azure Storage account that the web app should pull the WAR from. The WAR file could also be a JAR or EAR file.

-```bash

-curl -X POST -u <username> https://<app-name>.scm.azurewebsites.net/api/publish -d '{"packageUri": "https://storagesample.blob.core.windows.net/sample-container/myapp.war?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3"}'

-# [Kudu UI](#tab/kudu-ui)

-The Kudu UI does not support deploying JAR, WAR, or EAR applications. Please use one of the other options.

-The following example uses the cURL tool to deploy a startup file for their application.Replace the placeholders `<username>`, `<startup-file-path>`, and `<app-name>`. When prompted by cURL, type in the [deployment password](deploy-configure-credentials.md).

-curl -X POST -u <username> -T @"<startup-file-path>" https://<app-name>.scm.azurewebsites.net/api/publish?type=startup

-The following example uses the cURL tool to deploy a library file for their application. Replace the placeholders `<username>`, `<lib-file-path>`, and `<app-name>`. When prompted by cURL, type in the [deployment password](deploy-configure-credentials.md).

-curl -X POST -u <username> -T @"<lib-file-path>" "https://<app-name>.scm.azurewebsites.net/api/publish?type=lib&path=/home/site/deployments/tools/my-lib.jar"

-The following example uses the cURL tool to deploy a config file for their application. Replace the placeholders `<username>`, `<config-file-path>`, and `<app-name>`. When prompted by cURL, type in the [deployment password](deploy-configure-credentials.md).

-curl -X POST -u <username> -T @"<config-file-path>" "https://<app-name>.scm.azurewebsites.net/api/publish?type=static&path=/home/site/deployments/tools/my-config.json"

-# [Kudu UI](#tab/kudu-ui)

-The Kudu UI does not support deploying individual files. Please use the Azure CLI or Kudu REST API.

-The `publish` Kudu API allows you to specify the same parameters from the CLI command as URL query parameters. To authenticate with the Kudu API, you can use basic authentication with your app's [deployment credentials](deploy-configure-credentials.md#userscope).

-The table below shows the available query parameters, their allowed values, and descriptions.

-| `type` | `war`\|`jar`\|`ear`\|`lib`\|`startup`\|`static`\|`zip` | The type of the artifact being deployed, this sets the default target path and informs the web app how the deployment should be handled. <br/> - `type=zip`: Deploy a ZIP package by unzipping the content to `/home/site/wwwroot`. `target-path` parameter is optional. <br/> - `type=war`: Deploy a WAR package. By default, the WAR package is deployed to `/home/site/wwwroot/app.war`. The target path can be specified with `target-path`. <br/> - `type=jar`: Deploy a JAR package to `/home/site/wwwroot/app.jar`. The `target-path` parameter is ignored <br/> - `type=ear`: Deploy an EAR package to `/home/site/wwwroot/app.ear`. The `target-path` parameter is ignored <br/> - `type=lib`: Deploy a JAR library file. By default, the file is deployed to `/home/site/libs`. The target path can be specified with `target-path`. <br/> - `type=static`: Deploy a static file (e.g. a script). By default, the file is deployed to `/home/site/wwwroot`. <br/> - `type=startup`: Deploy a script that App Service automatically uses as the startup script for your app. By default, the script is deployed to `D:\home\site\scripts\<name-of-source>` for Windows and `home/site/wwwroot/startup.sh` for Linux. The target path can be specified with `target-path`. | Yes | String |

-| `target-path` | `"<absolute-path>"` | The absolute path to deploy the artifact to. For example, `"/home/site/deployments/tools/driver.jar"`, `"/home/site/scripts/helper.sh"`. | No | String |

-* [Azure App Service Deployment Credentials](deploy-ftp.md)

-1. Select the **Next: Deployment >** button at the bottom of the page.

-1. In the **Deployment** tab, under **GitHub Actions settings** make sure **Continuous deployment** is *Enable*.

-description: Deploy your first Go (GoLang) Hello World to Azure App Service in minutes.

-# Deploy a Go web app to Azure App Service

-> [!IMPORTANT]

-> Go on App Service on Linux is _experimental_.

->

-In this quickstart, you'll deploy a Go web app to Azure App Service. Azure App Service is a fully managed web hosting service that supports Go 1.19 and higher apps hosted in a Linux server environment.

-To complete this quickstart, you need:

-## 1 - Sample application

-First, create a folder for your project.

-Go to the terminal window, change into the folder you created and run `go mod init <ModuleName>`. The ModuleName could just be the folder name at this point.

-The `go mod init` command creates a go.mod file to track your code's dependencies. So far, the file includes only the name of your module and the Go version your code supports. But as you add dependencies, the go.mod file will list the versions your code depends on.

-Create a file called main.go. We'll be doing most of our coding here.

-```go

-package main

-import (

- "fmt"

- "net/http"

-)

-func main() {

- http.HandleFunc("/", HelloServer)

- http.ListenAndServe(":8080", nil)

-}

-func HelloServer(w http.ResponseWriter, r *http.Request) {

- fmt.Fprintf(w, "Hello, %s!", r.URL.Path[1:])

-}

-```

-This program uses the `net.http` package to handle all requests to the web root with the HelloServer function. The call to `http.ListenAndServe` tells the server to listen on the TCP network address `:8080`.

-Using a terminal, go to your projectΓÇÖs directory and run `go run main.go`. Now open a browser window and type the URL `http://localhost:8080/world`. You should see the message `Hello, world!`.

-## 2 - Create a web app in Azure

-To host your application in Azure, you need to create Azure App Service web app in Azure. You can create a web app using the Azure CLI.

-Azure CLI commands can be run on a computer with the [Azure CLI installed](/cli/azure/install-azure-cli).

-Azure CLI has a command `az webapp up` that will create the necessary resources and deploy your application in a single step.

-If necessary, log in to Azure using [az login](/cli/azure/authenticate-azure-cli).

-```azurecli

-az login

-```

-Create the webapp and other resources, then deploy your code to Azure using [az webapp up](/cli/azure/webapp#az-webapp-up).

-```azurecli

-az webapp up --runtime GO:1.19 --os linux --sku B1

-```

-* The `--runtime` parameter specifies what version of Go your app is running. This example uses Go 1.18. To list all available runtimes, use the command `az webapp list-runtimes --os linux --output table`.

-* The `--sku` parameter defines the size (CPU, memory) and cost of the app service plan. This example uses the B1 (Basic) service plan, which will incur a small cost in your Azure subscription. For a full list of App Service plans, view the [App Service pricing](https://azure.microsoft.com/pricing/details/app-service/linux/) page.

-* You can optionally specify a name with the argument `--name <app-name>`. If you don't provide one, then a name will be automatically generated.

-* You can optionally include the argument `--location <location-name>` where `<location_name>` is an available Azure region. You can retrieve a list of allowable regions for your Azure account by running the [`az account list-locations`](/cli/azure/appservice#az-appservice-list-locations) command.

-The command may take a few minutes to complete. While the command is running, it provides messages about creating the resource group, the App Service plan, and the app resource, configuring logging, and doing ZIP deployment. It then gives the message, "You can launch the app at http://&lt;app-name&gt;.azurewebsites.net", which is the app's URL on Azure.

-<pre>

-The webapp '&lt;app-name>' doesn't exist

-Creating Resource group '&lt;group-name>' ...

-Resource group creation complete

-Creating AppServicePlan '&lt;app-service-plan-name>' ...

-Creating webapp '&lt;app-name>' ...

-Creating zip with contents of dir /home/tulika/myGoApp ...

-Getting scm site credentials for zip deployment

-Starting zip deployment. This operation can take a while to complete ...

-Deployment endpoint responded with status code 202

-You can launch the app at http://&lt;app-name>.azurewebsites.net

-{

- "URL": "http://&lt;app-name>.azurewebsites.net",

- "appserviceplan": "&lt;app-service-plan-name>",

- "location": "centralus",

- "name": "&lt;app-name>",

- "os": "&lt;os-type>",

- "resourcegroup": "&lt;group-name>",

- "runtime_version": "go|1.19",

- "runtime_version_detected": "0.0",

- "sku": "FREE",

- "src_path": "&lt;your-folder-location>"

-}

-</pre>

-## 3 - Browse to the app

-Browse to the deployed application in your web browser at the URL `http://<app-name>.azurewebsites.net`. If you see a default app page, wait a minute and refresh the browser.

-The Go sample code is running a Linux container in App Service using a built-in image.

-**Congratulations!** You've deployed your Go app to App Service.

-## 4 - Clean up resources

-When no longer needed, you can use the [az group delete](/cli/azure/group#az-group-delete) command to remove the resource group, and all related resources:

-```azurecli-interactive

-az group delete --resource-group <resource-group-name>

-```

-## Next steps

-> [!div class="nextstepaction"]

-> [Configure an App Service app](./configure-common.md)

-> [!div class="nextstepaction"]

-> [Tutorial: Deploy from Azure Container Registry](./tutorial-custom-container.md)

-> [!div class="nextstepaction"]

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

-* [Azure CLI](/cli/azure/install-azure-cli) to run commands in any shell to provision and configure Azure resources.

-1. In a terminal window, run the following commands. It will clone the sample application to your local machine, and navigate to the directory containing the sample code.

-Azure CLI has a command [`az webapp up`](/cli/azure/webapp#az-webapp-up) that will create the necessary resources and deploy your application in a single step.

-az webapp up --runtime "PHP:8.0" --os-type=linux

-The command may take a few minutes to complete. While running, it provides messages about creating the resource group, the App Service plan, and the app resource, configuring logging, and doing ZIP deployment. It then gives the message, "You can launch the app at http://&lt;app-name&gt;.azurewebsites.net", which is the app's URL on Azure.

- "runtime_version": "php|8.0",

-1. On the **App Services** page, select **Create**.

- 

-1. Fill out the **Create Web App** page as follows.

- - **Resource Group**: Create a resource group named *myResourceGroup*.

- - **Name**: Type a globally unique name for your web app.

- - **Publish**: Select *Code*.

- - **Runtime stack**: Select *PHP 8.0*.

- - **Operating system**: Select *Linux*.

- - **Region**: Select an Azure region close to you.

- - **App Service Plan**: Create an app service plan named *myAppServicePlan*.

-1. To change to the Free tier, next to **Sku and size**, select **Change size**.

-

-1. In the Spec Picker, select **Dev/Test** tab, select **F1**, and select the **Apply** button at the bottom of the page.

- 

-1. Select the **Review + create** button at the bottom of the page.

-1. After validation runs, select the **Create** button at the bottom of the page. This will create an Azure resource group, app service plan, and app service.

-1. After the Azure resources are created, select **Go to resource**.

-

-1. From the left navigation, select **Deployment Center**.

- 

-1. Under **Settings**, select a **Source**. For this quickstart, select *GitHub*.

-1. In the section under **GitHub**, select the following settings:

- - Organization: Select your organization.

- - Repository: Select *php-docs-hello-world*.

- - Branch: Select the default branch for your repository.

-1. Select **Save**.

- 

- > [!TIP]

- > This quickstart uses GitHub. Additional continuous deployment sources include Bitbucket, Local Git, Azure Repos, and External Git. FTPS is also a supported deployment method.

-

-1. Once the GitHub integration is saved, from the left navigation of your app, select **Overview** > **URL**.

- 

-**Congratulations!** You've deployed your first PHP app to App Service using the Azure portal.

- az webapp up --runtime "PHP:8.0" --os-type=linux

-1. Once deployment has completed, return to the browser window that opened during the **Browse to the app** step, and refresh the page.

-1. On your repo page, press `.` to start Visual Studio code within your browser.

-

-> [!NOTE]

-> The URL will change from GitHub.com to GitHub.dev. This feature only works with repos that have files. This does not work on empty repos.

-1. Once deployment has completed, return to the browser window that opened during the **Browse to the app** step, and refresh the page.

- Your web app's **Overview** page will be displayed. Here, you can perform basic management tasks like **Browse**, **Stop**, **Restart**, and **Delete**.

-When you're finished with the sample app, you can remove all of the resources for the app from Azure. It will not incur extra charges and keep your Azure subscription uncluttered. Removing the resource group also removes all resources in the resource group and is the fastest way to remove all Azure resources for your app.

-This command may take a minute to run.

-When you deploy your application to the cloud, you choose a region in that cloud where your application infrastructure is based. If your application is deployed to a single region, and the region becomes unavailable, your application will also be unavailable. This lack of availability may be unacceptable under the terms of your application's SLA. If so, deploying your application and its services across multiple regions is a good solution.

-In this tutorial, you'll learn how to deploy a highly available multi-region web app. This scenario will be kept simple by restricting the application components to just a web app and [Azure Front Door](../frontdoor/front-door-overview.md), but the concepts can be expanded and applied to other infrastructure patterns. For example, if your application connects to an Azure database offering or storage account, see [active geo-replication for SQL databases](/azure/azure-sql/database/active-geo-replication-overview) and [redundancy options for storage accounts](../storage/common/storage-redundancy.md). For a reference architecture for a more detailed scenario, see [Highly available multi-region web application](/azure/architecture/reference-architectures/app-service-web-app/multi-region).

-The following architecture diagram shows the infrastructure you'll be creating during this tutorial. It consists of two identical App Services in separate regions, one being the active or primary region, and the other is the standby or secondary region. Azure Front Door is used to route traffic to the App Services and access restrictions are configured so that direct access to the apps from the internet is blocked. The dotted line indicates that traffic will only be sent to the standby region if the active region goes down.

-You'll need two instances of a web app that run in different Azure regions for this tutorial. You'll use the [region pair](../availability-zones/cross-region-replication-azure.md#azure-paired-regions) East US/West US as your two regions and create two empty web apps. Feel free to choose you're own regions if needed.

-To make management and clean-up simpler, you'll use a single resource group for all resources in this tutorial. Consider using separate resource groups for each region/resource to further isolate your resources in a disaster recovery situation.

-Once the App Service plans are created, run the following commands to create the web apps. Replace the placeholders for `<web-app-east-us>` and `<web-app-west-us>` with two globally unique names (valid characters are `a-z`, `0-9`, and `-`) and be sure to pay attention to the `--plan` parameter so that you place one app in each plan (and therefore in each region). Replace the `<runtime>` parameter with the language version of your app. Run `az webapp list-runtimes` for the list of available runtimes. If you plan on using the sample Node.js app given in this tutorial in the following sections, use "NODE:18-lts" as your runtime.

-You'll now create an [Azure Front Door Premium](../frontdoor/front-door-overview.md) to route traffic to your apps.

-Run [az afd profile create](/cli/azure/afd/profile#az-afd-profile-create) to create an Azure Front Door profile.

-> If you want to deploy Azure Front Door Standard instead of Premium, substitute the value of the `--sku` parameter with Standard_AzureFrontDoor. You won't be able to deploy managed rules with WAF Policy if you choose the Standard SKU. For a detailed comparison of the SKUs, see [Azure Front Door tier comparison](../frontdoor/standard-premium/tier-comparison.md).

-|profile-name |myfrontdoorprofile |Name for the Azure Front Door profile, which is unique within the resource group. |

-|resource-group |myresourcegroup |The resource group that contains the resources from this tutorial. |

-|sku |Premium_AzureFrontDoor |The pricing tier of the Azure Front Door profile. |

-Run [az afd endpoint create](/cli/azure/afd/endpoint#az-afd-endpoint-create) to create an endpoint in your profile. You can create multiple endpoints in your profile after finishing the create experience.

-|endpoint-name |myendpoint |Name of the endpoint under the profile, which is unique globally. |

-|enabled-state |Enabled |Whether to enable this endpoint. |

-Run [az afd origin-group create](/cli/azure/afd/origin-group#az-afd-origin-group-create) to create an origin group that contains your two web apps.

-|origin-group-name |myorigingroup |Name of the origin group. |

-|probe-request-type |GET |The type of health probe request that is made. |

-|probe-protocol |Http |Protocol to use for health probe. |

-|probe-interval-in-seconds |60 |The number of seconds between health probes. |

-|probe-path |/ |The path relative to the origin that is used to determine the health of the origin. |

-|sample-size |4 |The number of samples to consider for load balancing decisions. |

-|successful-samples-required |3 |The number of samples within the sample period that must succeed. |

-|additional-latency-in-milliseconds |50 |The additional latency in milliseconds for probes to fall into the lowest latency bucket. |

-Run [az afd origin create](/cli/azure/afd/origin#az-afd-origin-create) to add an origin to your origin group. For the `--host-name` parameter, replace the placeholder for `<web-app-east-us>` with your app name in that region. Notice the `--priority` parameter is set to "1", which indicates all traffic will be sent to your primary app.

-|host-name |`<web-app-east-us>.azurewebsites.net` |The hostname of the primary web app. |

-|origin-name |primaryapp |Name of the origin. |

-|origin-host-header |`<web-app-east-us>.azurewebsites.net` |The host header to send for requests to this origin. If you leave this blank, the request hostname determines this value. Azure CDN origins, such as Web Apps, Blob Storage, and Cloud Services require this host header value to match the origin hostname by default. |

-|priority |1 |Set this parameter to 1 to direct all traffic to the primary web app. |

-|weight |1000 |Weight of the origin in given origin group for load balancing. Must be between 1 and 1000. |

-|enabled-state |Enabled |Whether to enable this origin. |

-|http-port |80 |The port used for HTTP requests to the origin. |

-|https-port |443 |The port used for HTTPS requests to the origin. |

-Repeat this step to add your second origin. Pay attention to the `--priority` parameter. For this origin, it's set to "2". This priority setting tells Azure Front Door to direct all traffic to the primary origin unless the primary goes down. If you set the priority for this origin to "1", Azure Front Door will treat both origins as active and direct traffic to both regions. Be sure to replace both instances of the placeholder for `<web-app-west-us>` with the name of that web app.

-Run [az afd route create](/cli/azure/afd/route#az-afd-route-create) to map your endpoint to the origin group. This route forwards requests from the endpoint to your origin group.

-|endpoint-name |myendpoint |Name of the endpoint. |

-|forwarding-protocol |MatchRequest |Protocol this rule will use when forwarding traffic to backends. |

-|route-name |route |Name of the route. |

-|https-redirect |Enabled |Whether to automatically redirect HTTP traffic to HTTPS traffic. |

-|supported-protocols |Http Https |List of supported protocols for this route. |

-|link-to-default-domain |Enabled |Whether this route will be linked to the default endpoint domain. |

-Allow about 15 minutes for this step to complete as it takes some time for this change to propagate globally. After this period, your Azure Front Door will be fully functional.

-If you try to access your apps directly using their URLs at this point, you'll still be able to. To ensure traffic can only reach your apps through Azure Front Door, you'll set access restrictions on each of your apps. Front Door's features work best when traffic only flows through Front Door. You should configure your origins to block traffic that hasn't been sent through Front Door. Otherwise, traffic might bypass Front Door's web application firewall, DDoS protection, and other security features. Traffic from Azure Front Door to your applications originates from a well known set of IP ranges defined in the AzureFrontDoor.Backend service tag. By using a service tag restriction rule, you can [restrict traffic to only originate from Azure Front Door](../frontdoor/origin-security.md).

-Before setting up the App Service access restrictions, take note of the *Front Door ID* by running the following command. This ID will be needed to ensure traffic only originates from your specific Front Door instance. The access restriction further filters the incoming requests based on the unique HTTP header that your Azure Front Door sends.

-Run [az afd endpoint show](/cli/azure/afd/endpoint#az-afd-endpoint-show) to get the hostname of the Front Door endpoint.

-In a browser, go to the endpoint hostname that the previous command returned: `<myendpoint>-<hash>.z01.azurefd.net`. Your request will automatically get routed to the primary app in East US.

- > You might need to refresh the page a couple times as failover may take a couple seconds.

-This command may take a few minutes to run.

-For this tutorial, you used the Azure CLI to deploy your infrastructure resources. Consider configuring a continuous deployment mechanism to manage your application infrastructure. Since you're deploying resources in different regions, you'll need to independently manage those resources across the regions. To ensure the resources are identical across each region, infrastructure as code (IaC) such as [Azure Resource Manager templates](../azure-resource-manager/management/overview.md) or [Terraform](/azure/developer/terraform/overview) should be used with deployment pipelines such as [Azure Pipelines](/azure/devops/pipelines/get-started/what-is-azure-pipelines) or [GitHub Actions](https://docs.github.com/actions). This way, if configured appropriately, any change to resources would trigger updates across all regions you're deployed to. For more information, see [Continuous deployment to Azure App Service](deploy-continuous-deployment.md).

-Deploying your application code directly to production apps/slots isn't recommended. This is because you'd want to have a safe place to test your apps and validate changes you've made before pushing to production. Use a combination of staging slots and slot swap to move code from your testing environment to production.

-You already created the baseline infrastructure for this scenario. You'll now create deployment slots for each instance of your app and configure continuous deployment to these staging slots with GitHub Actions. As with infrastructure management, configuring continuous deployment for your application source code is also recommended to ensure changes across regions are in sync. If you donΓÇÖt configure continuous deployment, youΓÇÖll need to manually update each app in each region every time there's a code change.

-Be sure to set the App Service stack settings for your apps. Stack settings refer to the language or runtime used for your app. This setting can be configured using the Azure CLI with the `az webapp config set` command or in the portal with the following steps. If you use the Node.js sample, set the stack settings to "Node 18 LTS".

-### How do I disable basic auth on App Service?

-Consider [disabling basic auth on App Service](https://azure.github.io/AppService/2020/08/10/securing-data-plane-access.html), which limits access to the FTP and SCM endpoints to users that are backed by Microsoft Entra ID. If using a continuous deployment tool to deploy your application source code, disabling basic auth will require [extra steps to configure continuous deployment](deploy-github-actions.md). For example, you won't be able to use a publish profile since that authentication mechanism doesn't use Microsoft Entra backed credentials. Instead, you'll need to use either a [service principal or OpenID Connect](deploy-github-actions.md#generate-deployment-credentials).

-To disable basic auth for your App Service, run the following commands for each app and slot by replacing the placeholders for `<web-app-east-us>` and `<web-app-west-us>` with your app names. The first set of commands disables FTP access for the production sites and staging slots, and the second set of commands disables basic auth access to the WebDeploy port and SCM site for the production sites and staging slots.

-For more information on disabling basic auth including how to test and monitor logins, see [Disabling basic auth on App Service](https://azure.github.io/AppService/2020/08/10/securing-data-plane-access.html).

-1. Run the following command to create the [service principal](../active-directory/develop/app-objects-and-service-principals.md#service-principal-object). Replace the placeholders with your `<subscription-id>` and app names. The output is a JSON object with the role assignment credentials that provide access to your App Service apps. Copy this JSON object for the next step. It will include your client secret, which will only be visible at this time. It's always a good practice to grant minimum access. The scope in this example is limited to just the apps, not the entire resource group.

-1. You need to provide your service principal's credentials to the Azure Login action as part of the GitHub Action workflow you'll be using. These values can either be provided directly in the workflow or can be stored in GitHub secrets and referenced in your workflow. Saving the values as GitHub secrets is the more secure option.

-Now that you have a service principal that can access your App Service apps, edit the default workflows that were created for your apps when you configured continuous deployment. Authentication must be done using your service principal instead of the publish profile. For sample workflows, see the "Service principal" tab in [Deploy to App Service](deploy-github-actions.md#deploy-to-app-service). The following sample workflow can be used for the Node.js sample app that was provided.

-1. Open your app's GitHub repository and go to the `<repo-name>/.github/workflows/` directory. You'll see the autogenerated workflows.

-1. For each workflow file, select the "pencil" button in the top right to edit the file. Replace the contents with the following text, which assumes you created the GitHub secrets earlier for your credential. Update the placeholder for `<web-app-name>` under the "env" section, and then commit directly to the main branch. This commit will trigger the GitHub Action to run again and deploy your code, this time using the service principal to authenticate.

-Traffic routing with slots allows you to direct a pre-defined portion of your user traffic to each slot. Initially, 100% of traffic is directed to the production site. However, you have the ability, for example, to send 10% of your traffic to your staging slot. If you configure slot traffic routing in this way, when users try to access your app, 10% of them will automatically be routed to the staging slot with no changes to your Front Door instance. To learn more about slot swaps and staging environments in App Service, see [Set up staging environments in Azure App Service](deploy-staging-slots.md).

-Once you're done testing and validating in your staging slots, you can perform a [slot swap](deploy-staging-slots.md#swap-two-slots) from your staging slot to your production site. You'll need to do this swap for all instances of your app in each region. During a slot swap, the App Service platform [ensures the target slot doesn't experience downtime](deploy-staging-slots.md#swap-operation-steps).

-At this point, your apps are up and running and any changes you make to your application source code will automatically trigger an update to both of your staging slots. You can then repeat the slot swap process when you're ready to move that code into production.

-If you're concerned about potential disruptions or issues with continuity across regions, as in some customers seeing one version of your app while others see another version, or if you're making significant changes to your apps, you can temporarily remove the site that's undergoing the slot swap from your Front Door's origin group. All traffic will then be directed to the other origin. Navigate to the **Update origin group** pane and **Delete** the origin that is undergoing the change. Once you've made all of your changes and are ready to serve traffic there again, you can return to the same pane and select **+ Add an origin** to readd the origin.

-To demonstrate working with multiple origins, in the following screenshot, there are three origin groups. "MyOriginGroup" consists of both web apps, and the other two origin groups each consist of the web app in their respective region. In the example, the app in the primary region is undergoing a change. Before that change was started, the route was associated with "MySecondaryRegion" so all traffic would be sent to the app in the secondary region during the change period. You can update the route by selecting "Unassociated", which will bring up the **Associate routes** pane.

-With Azure App service, the SCM/advanced tools site is used to manage your apps and deploy application source code. Consider [locking down the SCM/advanced tools site](app-service-ip-restrictions.md#restrict-access-to-an-scm-site) since this site will most likely not need to be reached through Front Door. For example, you can set up access restrictions that only allow you to conduct your testing and enable continuous deployment from your tool of choice. If you're using deployment slots, for production slots specifically, you can deny almost all access to the SCM site since your testing and validation will be done with your staging slots.

-Your Deployment Center configuration has created a default workflow file in each of your sample repositories, but it uses a publish profile by default, which uses basic auth. Since you've disabled basic auth, if you check the **Logs** tab in Deployment Center, you'll see that the automatically triggered deployment results in an error. You must modify the workflow file to use the service principal to authenticate with App Service. For sample workflows, see [Deploy to App Service](deploy-github-actions.md?tabs=userlevel#deploy-to-app-service).

-Since in this tutorial you've [disabled basic auth](#5-lock-down-ftp-and-scm-access), you can't authenticate with the back end SCM site with a username and password, and neither can you with a publish profile. Instead of a service principal, you can also use [OpenID Connect](deploy-github-actions.md?tabs=openid#deploy-to-app-service).

->FRun the `Set-AzContext -Subscription <V1 application gateway SubscriptionId>` cmdlet every time before running the migration script. This is necessary to set the active Azure context to the correct subscription, because the migration script might clean up the existing resource group if it doesn't exist in current subscription context.This is not a mandatory step for version 1.0.11 & above of the migration script.

- - EXEC sp_addrolemember `dbowner`, "AutomationAccount"

- <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.20.1" />

- <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.20.1" />

- <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.20.1" />

-| [Cloud sync](#cloud-sync)¹ |Γ£ö|Γ£ö|Γ£ö| |Γ£ö|Γ£ö|

-### Cloud sync

-Use cloud sync to sync your content from Dropbox and OneDrive to Azure Functions.

->__How to use it:__ Follow the instructions in [Sync content from a cloud folder](../app-service/deploy-content-sync.md).

->__When to use it:__ To reduce the chance of errors, you should avoid using deployment methods that require the additional step of [manually syncing triggers](#trigger-syncing). Use [zip deployment](run-functions-from-deployment-package.md) when possible.

->__Where app content is stored:__ The app content is in the cloud store, but a local copy is stored on the app file system, which may be backed by Azure Files from the storage account specified when the function app was created.

- <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.20.1" />

- <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.CosmosDB" Version="4.5.1" />

- <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.20.1" />

- <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.ServiceBus" Version="5.15.0" />

-To verify the Azure Monitor Agent Troubleshooter is presence, copy the following command and run in Bash as root:

-When you create a log alert rule with system-assigned managed identity, the identity is created without any permissions. After you create the rule, you need to assign the appropriate roles to the ruleΓÇÖs identity so that it can access the data you want to query. For example, you might need to give it a Reader role for the relevant Log Analytics workspaces, or a Reader role and a Database Viewer role for the relevant ADX cluster. See [managed identities](alerts-create-new-alert-rule.md#managed-id) for more information about using managed identities in log alerts.

- - [Community alerts](https://aka.ms/azureprometheus-communityalerts)

- - [Recommended alerts](https://aka.ms/azureprometheus-recommendedalerts)

-1. To deploy community and recommended alerts, follow this [template](https://aka.ms/azureprometheus-alerts-bicep) and follow the README.md file in the same folder for how to deploy.

-

-These handpicked alerts come from the Prometheus community. Source code for these mixin alerts can be found in [GitHub](https://aka.ms/azureprometheus-communityalerts):

-Source code for the recommended alerts can be found in [GitHub](https://github.com/Azure/prometheus-collector/blob/68ab5b195a77d72b0b8e36e5565b645c3d1e2d5d/mixins/kubernetes/rules/recording_and_alerting_rules/templates/ci_recommended_alerts.json):

-### Pod annotation-based scraping

-The following scrape config uses the `__meta_*` labels added from the `kubernetes_sd_configs` for the `pod` role to filter for pods with certain annotations.

-To scrape certain pods, specify the port, path, and scheme through annotations for the pod and the following job scrapes only the address specified by the annotation:

-```yaml

-scrape_configs:

- - job_name: 'kubernetespods-sample'

- kubernetes_sd_configs:

- - role: pod

- relabel_configs:

- # Scrape only pods with the annotation: prometheus.io/scrape = true

- - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]

- action: keep

- regex: true

- # If prometheus.io/path is specified, scrape this path instead of /metrics

- - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]

- action: replace

- target_label: __metrics_path__

- regex: (.+)

- # If prometheus.io/port is specified, scrape this port instead of the default

- - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]

- action: replace

- regex: ([^:]+)(?::\d+)?;(\d+)

- replacement: $1:$2

- target_label: __address__

- # If prometheus.io/scheme is specified, scrape with this scheme instead of http

- - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme]

- action: replace

- regex: (http|https)

- target_label: __scheme__

- # Include the pod namespace as a label for each metric

- - source_labels: [__meta_kubernetes_namespace]

- action: replace

- target_label: kubernetes_namespace

- # Include the pod name as a label for each metric

- - source_labels: [__meta_kubernetes_pod_name]

- action: replace

- target_label: kubernetes_pod_name

- # [Optional] Include all pod labels as labels for each metric

- - action: labelmap

- regex: __meta_kubernetes_pod_label_(.+)

-```

-See the [Apply config file](prometheus-metrics-scrape-validate.md#deploy-config-file-as-configmap) section to create a configmap from the Prometheus config.

-1. On the **Azure Monitor** menu in the Azure portal, select **Data Collection Endpoints** under the **Settings** section. Select **Create** to create a new DCR and assignment.

-| **OS versions** | SLES 12 with SP2, SP3, SP4 and SP5; SLES 15 with SP0, SP1, SP2, SP3, SP4, and SP5 <br><br> RHEL 7.4, 7.6, 7.7, 7.9, 8.1, 8.2, 8.4, 8.6, 8.8, and 9.0. | |

-Learn more about [SAP HANA Azure Virtual Machine storage](/azure/sap/workloads/hana-vm-operations-storage) and [SAP HANA Azure virtual machine Premium SSD storage configurations](/azure/sap/workloads/hana-vm-premium-ssd-v1) configurations.

-zone_pivot_groups: acs-azcli-azp-java-net-python-csharp-js

-| [Generally Available: Github Actions for Azure Container Apps](./github-actions.md) | Azure Container Apps allows you to use GitHub Actions to publish revisions to your container app. |

-# Sign container images with Notation and Azure Key Vault using a self-signed certificate (Preview)

-> [!IMPORTANT]

-> This feature is currently in preview. Previews are made available to you on the condition that you agree to the [supplemental terms of use][terms-of-use]. Some aspects of this feature may change prior to general availability (GA).

-# Sign container images with Notation and Azure Key Vault using a CA-issued certificate (Preview)

-> [!IMPORTANT]

-> This feature is currently in preview. Previews are made available to you on the condition that you agree to the [supplemental terms of use][terms-of-use]. Some aspects of this feature may change prior to general availability (GA).

-To get help building infrastructure and deploying workloads, start on the [More virtual machines and related solutions](https://portal.azure.com/?feature.customportal=false#view/Microsoft_Azure_SolutionCenter/SolutionGroup.ReactView/groupid/defaultLandingVmBrowse) page in the Azure portal.

-From the **More virtual machines and related solutions** page, you can tell Microsoft Copilot for Azure (preview) "**I want to deploy a website on Azure**." Microsoft Copilot for Azure (preview) responds with a series of questions to better understand your scenario.

- | [AWS registry container images should have vulnerability findings resolved (powered by Microsoft Defender Vulnerability Management) - Microsoft Azure](https://ms.portal.azure.com/#view/Microsoft_Azure_Security_CloudNativeCompute/AwsContainerRegistryRecommendationDetailsBlade/assessmentKey/c27441ae-775c-45be-8ffa-655de37362ce) | Scans your AWS registries container images for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. Resolving vulnerabilities can greatly improve your security posture, ensuring images are safe to use prior to deployment. | c27441ae-775c-45be-8ffa-655de37362ce |

- | [AWS running container images should have vulnerability findings resolved (powered by Microsoft Defender Vulnerability Management) - Microsoft Azure](https://ms.portal.azure.com/#view/Microsoft_Azure_Security_CloudNativeCompute/AwsContainersRuntimeRecommendationDetailsBlade/assessmentKey/682b2595-d045-4cff-b5aa-46624eb2dd8f)ΓÇ»| Container image vulnerability assessment scans your registry for commonly known vulnerabilities (CVEs) and provides a detailed vulnerability report for each image. This recommendation provides visibility to vulnerable images currently running in your Elastic Kubernetes clusters. Remediating vulnerabilities in container images that are currently running is key to improving your security posture, significantly reducing the attack surface for your containerized workloads. | 682b2595-d045-4cff-b5aa-46624eb2dd8f |

-For more help, contact the Azure experts on the [MSDN Azure and Stack Overflow forums](https://azure.microsoft.com/support/forums/). Or file an Azure support incident. Go to the [Azure support site](https://azure.microsoft.com/support/options/) and select Get support. For information about using Azure Support, read the [Microsoft Azure support common questions](https://azure.microsoft.com/support/faq/).

-1. Install [ngnix ingress Controller](https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-helm/) :

-1. Create ECR repository named *mdc-mock-0001*

-1. Install [ngnix ingress Controller](https://docs.nginx.com/nginx-ingress-controller/installation/installation-with-helm/) :

- description = properties.displayName,

- cve = properties.additionalData.cve,

-| [Enforcement of Defender CSPM for Premium DevOps Security Capabilities](#enforcement-of-defender-cspm-for-premium-devops-security-value) | January 29, 2024 | March 2024 |

-In Azure, agentless scanning for VMs uses a built-in role (called [VM scanner operator](/azure/defender-for-cloud/faq-permissions)) with the minimum necessary permissions required to scan and assess your VMs for security issues. To continuously provide relevant scan health and configuration recommendations for VMs with encrypted volumes, an update to this role's permissions is planned. The update includes the addition of the ```Microsoft.Compute/DiskEncryptionSets/read``` permission. This permission solely enables improved identification of encrypted disk usage in VMs. It does not provide Defender for Cloud any additional capabilities to decrypt or access the content of these encrypted volumes beyond the encryption methods [already supported](/azure/defender-for-cloud/concept-agentless-data-collection#availability) prior to this change. This change is expected to take place during February 2024 and no action is required on your end.

-The Defender for Servers built-in vulnerability assessment solution powered by Qualys is on a retirement path which is estimated to complete on **May 1st, 2024**. If you're currently using the vulnerability assessment solution powered by Qualys, you should plan your [transition to the integrated Microsoft Defender vulnerability management solution](how-to-transition-to-built-in.md).

-## Enforcement of Defender CSPM for Premium DevOps Security Value

-**Announcement date: January 29, 2023**

-**Estimated date for change: March 7, 2024**

-Defender for Cloud will begin enforcing the Defender CSPM plan check for premium DevOps security value beginning **March 7th, 2024**. If you have the Defender CSPM plan enabled on a cloud environment (Azure, AWS, GCP) within the same tenant your DevOps connectors are created in, you will continue to receive premium DevOps capabilities at no additional cost. If you are not a Defender CSPM customer, you have until **March 7th, 2024** to enable Defender CSPM before losing access to these security features. To enable Defender CSPM on a connected cloud environment before March 7th, 2024, follow the enablement documentation outlined [here](tutorial-enable-cspm-plan.md#enable-the-components-of-the-defender-cspm-plan).

-For more information about which DevOps security features are available across both the Foundational CSPM and Defender CSPM plans, see [our documentation outlining feature availability](devops-support.md#feature-availability).

-For more information about DevOps Security in Defender for Cloud, see the [overview documentation](defender-for-devops-introduction.md).

-For more information on the code to cloud security capabilities in Defender CSPM, see [how to protect your resources with Defender CSPM](tutorial-enable-cspm-plan.md).

-| Communication with suspicious random domain name (Preview) | DNS_RandomizedDomain

-Azure Front Door Classic/Standard/Premium SKUs are available in Microsoft Azure (Commercial) and Azure Front Door Classic SKU is available in Microsoft Azure Government (US).

-The Device Update for IoT Hub Core PnP interface reports `ResultCode` and `ExtendedResultCode`, which can be used to diagnose failures. For more information about the Device Update Core PnP interface, see [Device Update and Plug and Play](device-update-plug-and-play.md). For more details regarding the default meanings of Device Update agent ResultCode and ExtendedResultCodes, see the [Device Update Github repository](https://aka.ms/du-resultcodes).

- > If you're using Github Codespaces in a browser, `az login` returns a localhost error in the browser window after logging in. To fix, either:

-By default, the Expiration time for a dataset is set to `12h`. This default ensures that no stale data is enriched beyond 12 hours (if the data is not updated) or grow unbounded which can fill up the disk.

-| Property name | `asset` |

-# Model monitoring with Azure Machine Learning (preview)

-Model monitoring is the last step in the machine learning end-to-end lifecycle. This step tracks model performance in production and aims to understand it from both data science and operational perspectives. Unlike traditional software systems, the behavior of machine learning systems is governed not just by rules specified in code, but also by model behavior learned from data. Data distribution changes, training-serving skew, data quality issues, shift in environment, or consumer behavior changes can all cause models to become stale and their performance to degrade to the point that they fail to add business value or start to cause serious compliance issues in highly regulated environments.

-To implement monitoring, Azure Machine Learning acquires monitoring signals through data analysis on streamed production inference data and reference data. The reference data can include historical training data, validation data, or ground truth data. Each monitoring signal has one or more metrics. Users can set thresholds for these metrics in order to receive alerts via Azure Machine Learning or Azure Monitor about model or data anomalies. These alerts can prompt users to analyze or troubleshoot monitoring signals in Azure Machine Learning studio for continuous model quality improvement.

-* **Built-in monitoring signals**. Model monitoring provides built-in monitoring signals for tabular data. These monitoring signals include data drift, prediction drift, data quality, and feature attribution drift.

-* **Use of recent past production data or training data as reference data for comparison**. For monitoring signals, Azure Machine Learning lets you set reference data using recent past production data or training data.

-* **Monitoring of top N features for data drift or data quality**. If you use training data as the reference data, you can define data drift or data quality signals layering over feature importance.

-* **Flexibility to use production inference data from any source**. If you deploy models outside of Azure Machine Learning, or if you deploy models to Azure Machine Learning batch endpoints, you can collect production inference data. You can then use the inference data in Azure Machine Learning for model monitoring.

-* **Flexibility to select data window**. You have the flexibility to select a data window for both the production data and the reference data.

- * By default, the data window for production data is your monitoring frequency. That is, all data collected in the past monitoring period before the monitoring job is run will be analyzed. You can use the `production_data.data_window_size` property to adjust the data window for the production data, if needed.

- * By default, the data window for the reference data is the full dataset. You can adjust the reference data window with the `reference_data.data_window` property. Both rolling data window and fixed data window are supported.

-Azure Machine Learning model monitoring (preview) supports the following list of monitoring signals and metrics:

-| Data drift | Data drift tracks changes in the distribution of a model's input data by comparing it to the model's training data or recent past production data. | Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Two-Sample Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test | Classification (tabular data), Regression (tabular data) | Production data - model inputs | Recent past production data or training data |

-| Prediction drift | Prediction drift tracks changes in the distribution of a model's prediction outputs by comparing it to validation or test labeled data or recent past production data. | Jensen-Shannon Distance, Population Stability Index, Normalized Wasserstein Distance, Chebyshev Distance, Two-Sample Kolmogorov-Smirnov Test, Pearson's Chi-Squared Test | Classification (tabular data), Regression (tabular data) | Production data - model outputs | Recent past production data or validation data |

-| Data quality | Data quality tracks the data integrity of a model's input by comparing it to the model's training data or recent past production data. The data quality checks include checking for null values, type mismatch, or out-of-bounds of values. | Null value rate, data type error rate, out-of-bounds rate | Classification (tabular data), Regression (tabular data) | production data - model inputs | Recent past production data or training data |

-| Feature attribution drift | Feature attribution drift tracks the contribution of features to predictions (also known as feature importance) during production by comparing it with feature importance during training.| Normalized discounted cumulative gain | Classification (tabular data), Regression (tabular data) | Production data - model inputs & outputs | Training data (required) |

-|[Generative AI: Generation safety and quality](./prompt-flow/how-to-monitor-generative-ai-applications.md)|Evaluates generative AI applications for safety & quality using GPT-assisted metrics.| Groundedness, relevance, fluency, similarity, coherence|text_question_answering| prompt, completion, context, and annotation template |N/A|

-

-## How model monitoring works in Azure Machine Learning

-Azure Machine Learning acquires monitoring signals by performing statistical computations on production inference data and reference data. This reference data can include the model's training data or validation data, while the production inference data refers to the model's input and output data collected in production.

-The following steps describe an example of the statistical computation used to acquire a data drift signal for a model that's in production.

-* For a feature in the training data, calculate the statistical distribution of its values. This distribution is the baseline distribution.

-* Calculate the statistical distribution of the feature's latest values that are seen in production.

-* Compare the distribution of the feature's latest values in production against the baseline distribution by performing a statistical test or calculating a distance score.

-* When the test statistic or the distance score between the two distributions exceeds a user-specified threshold, Azure Machine Learning identifies the anomaly and notifies the user.

-### Enabling model monitoring

-Take the following steps to enable model monitoring in Azure Machine Learning:

-* **Enable production inference data collection.** If you deploy a model to an Azure Machine Learning online endpoint, you can enable production inference data collection by using Azure Machine Learning [Model Data Collection](concept-data-collection.md). However, if you deploy a model outside of Azure Machine Learning or to an Azure Machine Learning batch endpoint, you're responsible for collecting production inference data. You can then use this data for Azure Machine Learning model monitoring.

-* **Set up model monitoring.** You can use SDK/CLI 2.0 or the studio UI to easily set up model monitoring. During the setup, you can specify your preferred monitoring signals and customize metrics and thresholds for each signal.

-* **View and analyze model monitoring results.** Once model monitoring is set up, a monitoring job is scheduled to run at your specified frequency. Each run computes and evaluates metrics for all selected monitoring signals and triggers alert notifications when any specified threshold is exceeded. You can follow the link in the alert notification to your Azure Machine Learning workspace to view and analyze monitoring results.

-* **Start model monitoring as soon as your model is deployed to production.**

-* **Work with data scientists that are familiar with the model to set up model monitoring.** Data scientists who have insight into the model and its use cases are in the best position to recommend monitoring signals and metrics as well as set the right alert thresholds for each metric (to avoid alert fatigue).

-* **Include multiple monitoring signals in your monitoring setup.** With multiple monitoring signals, you get both a broad view and granular view of monitoring. For example, you can combine both data drift and feature attribution drift signals to get an early warning about your model performance issue.

-* **Specify the monitoring frequency based on how your production data will grow over time**. For example, if your production model has much traffic daily, and the daily data accumulation is sufficient for you to monitor, then you can set the monitoring frequency to daily. Otherwise, you can consider a weekly or monthly monitoring frequency, based on the growth of your production data over time.

-## Next steps

-Also see the [demand forecasting with hierarchical time series notebook](https://github.com/Azure/azureml-examples/blob/main/sdk/python/jobs/pipelines/1k_demand_forecasting_with_pipeline_components/automl-forecasting-demand-hierarchical-timeseries-in-pipeline/automl-forecasting-demand-hierarchical-timeseries-in-pipeline.ipynb) for a more detailed example.

-In this article, you'll learn how to collect production inference data from a model deployed to an Azure Machine Learning managed online endpoint or Kubernetes online endpoint.

-Azure Machine Learning **Data collector** logs inference data in Azure blob storage. You can enable data collection for new or existing online endpoint deployments.

-Data collected with the provided Python SDK is automatically registered as a data asset in your Azure Machine Learning workspace. This data asset can be used for model monitoring.

-If you're interested in collecting production inference data for a MLFlow model deployed to a real-time endpoint, doing so can be done with a single toggle. To learn how to do this, see [Data collection for MLFlow models](#collect-data-for-mlflow-models).

-# [Python](#tab/python)

-* Have a registered model that you can use for deployment. If you haven't already registered a model, see [Register your model as an asset in Machine Learning](how-to-manage-models.md#register-your-model-as-an-asset-in-machine-learning-by-using-the-cli).

-Data collection with custom logging allows you to log pandas DataFrames directly from your scoring script before, during, and after any data transformations. With custom logging, tabular data is logged in real-time to your workspace Blob storage or a custom Blob storage container. From storage, it can be consumed by your model monitors.

-First, you'll need to add custom logging code to your scoring script (`score.py`). For custom logging, you'll need the `azureml-ai-monitoring` package. For more information, see the comprehensive [PyPI page for the data collector SDK](https://pypi.org/project/azureml-ai-monitoring/).

- > If you use the names `model_inputs` and `model_outputs` for your `Collector` objects, the model monitoring system will automatically recognize the automatically registered data assets, which will provide for a more seamless model monitoring experience.

- inputs_outputs_collector = Collector(name='model_inputs_outputs')

- > Currently, only pandas DataFrames can be logged with the `collect()` API. If the data is not in a DataFrame when passed to `collect()`, it will not be logged to storage and an error will be reported.

-The following code is an example of a full scoring script (`score.py`) that uses the custom logging Python SDK. In this example, a third `Collector` called `inputs_outputs_collector` logs a joined DataFrame of the `model_inputs` and the `model_outputs`. This joined DataFrame enables additional monitoring signals (feature attribution drift, etc.). If you are not interested in those monitoring signals, please feel free to remove this `Collector`.

- inputs_outputs_collector = Collector(name='model_inputs_outputs') #note: this is used to enable Feature Attribution Drift

- # create a dataframe with inputs/outputs joined - this creates a URI folder (not mltable)

- # input_output_df = input_df.merge(output_df, context)

- input_output_df = input_df.join(output_df)

- # collect both your inputs and output

- inputs_outputs_collector.collect(input_output_df, context)

-Before you create your deployment with the updated scoring script, you'll create your environment with the base image `mcr.microsoft.com/azureml/openmpi4.1.0-ubuntu20.04` and the appropriate conda dependencies, then you'll build the environment using the specification in the following YAML.

-Next, we'll create the deployment YAML. Include the `data_collector` attribute and enable collection for `model_inputs` and `model_outputs`, which are the names we gave our `Collector` objects earlier via the custom logging Python SDK:

- model_inputs_outputs:

- enabled: 'True'

-The following code is an example of a comprehensive deployment YAML for a managed online endpoint deployment. You should update the deployment YAML according to your scenario. For more examples on how to format your deployment YAML for inference data logging, see [https://github.com/Azure/azureml-examples/tree/main/cli/endpoints/online/data-collector](https://github.com/Azure/azureml-examples/tree/main/cli/endpoints/online/data-collector).

- model_inputs_outputs:

- enabled: 'True'

-Optionally, you can adjust the following additional parameters for your `data_collector`:

-#### Collect data to a custom Blob storage container

-If you need to collect your production inference data to a custom Blob storage container, you can do so with the data collector.

-To use the data collector with a custom Blob storage container, connect the storage container to an Azure Machine Learning datastore. To learn how to do so, see [create datastores](how-to-datastore.md).

-Next, ensure that your Azure Machine Learning endpoint has the necessary permissions to write to the datastore destination. The data collector supports both system assigned managed identities (SAMIs) and user assigned managed identities (UAMIs). Add the identity to your endpoint. Assign the role `Storage Blob Data Contributor` to this identity with the Blob storage container which will be used as the data destination. To learn how to use managed identities in Azure, see [assign Azure roles to a managed identity](/azure/role-based-access-control/role-assignments-portal-managed-identity).

-Then, update your deployment YAML to include the `data` property within each collection. The `data.name` is a required parameter used to specify the name of the data asset to be registered with the collected data. The `data.path` is a required parameter used to specify the fully-formed Azure Machine Learning datastore path, which is connected to your Azure Blob storage container. The `data.version` is an optional parameter used to specify the version of the data asset (defaults to 1).

-Here is an example YAML configuration of how you would do so:

-```yml

-data_collector:

- collections:

- model_inputs:

- enabled: 'True'

- data:

- name: my_model_inputs_data_asset

- path: azureml://datastores/workspaceblobstore/paths/modelDataCollector/my_endpoint/blue/model_inputs

- version: 1

- model_outputs:

- enabled: 'True'

- data:

- name: my_model_outputs_data_asset

- path: azureml://datastores/workspaceblobstore/paths/modelDataCollector/my_endpoint/blue/model_outputs

- version: 1

-```

-**Note**: You can also use the `data.path` parameter to point to datastores in different Azure subscriptions. To do so, ensure your path looks like this: `azureml://subscriptions/<sub_id>/resourcegroups/<rg_name>/workspaces/<ws_name>/datastores/<datastore_name>/paths/<path>`

-For more information on how to format your deployment YAML for data collection (along with default values) with kubernetes online endpoints, see the [CLI (v2) Azure Arc-enabled Kubernetes online deployment YAML schema](reference-yaml-deployment-kubernetes-online.md). For more information on how to format your deployment YAML for data collection with managed online endpoints, see [CLI (v2) managed online deployment YAML schema](reference-yaml-deployment-managed-online.md).

-Blob storage output/format

-By default, the collected data will be stored at the following path in your workspace Blob storage: `azureml://datastores/workspaceblobstore/paths/modelDataCollector`. The final path in Blob will be appended with `{endpoint_name}/{deployment_name}/{collection_name}/{yyyy}/{MM}/{dd}/{HH}/{instance_id}.jsonl`. Each line in the file is a JSON object representing a single inference request/response that was logged.

-> `collection_name` refers to the MDC data collection name (e.g., "model_inputs" or "model_outputs"). `instance_id` is a unique id identifying the grouping of data which was logged.

-The collected data will follow the following json schema. The collected data is available from the `data` key and additional metadata is provided.

-> [!NOTE]

-If the payload of your data is greater than 256 kb, 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.

-#### Viewing the data in the studio UI

-To view the collected data in Blob storage from the studio UI:

-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`). 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'

-```

-Deploy the model with payload logging enabled:

-```bash

-$ az ml online-deployment create -f deployment.YAML

-```

-> [!NOTE]

-> With payload logging, the collected data is not guaranteed to be in tabular format. Because of this, if you want to use collected payload data with model monitoring, you'll be required to provide a pre-processing 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 will flow to your workspace Blob storage. The following code is an example of an HTTP _request_ collected JSON:

-And the following code is an example of an HTTP _response_ collected JSON:

-## Collect data for MLFlow models

-If you're deploying an MLFlow model to an Azure Machine Learning online endpoint, you can enable production inference data collection with single toggle in the studio UI. If data collection is toggled on, we'll auto-instrument your scoring script with custom logging code to ensure that the production data is logged to your workspace Blob storage. The data can then be used by your model monitors to monitor the performance of your MLFlow model in production.

-To enable production data collection, while you're deploying your model, under the **Deployment** tab, select **Enabled** for **Data collection (preview)**.

-After enabling data collection, production inference data will be logged to your Azure Machine Learning workspace blob storage and two data assets will be created with names `<endpoint_name>-<deployment_name>-model_inputs` and `<endpoint_name>-<deployment_name>-model_outputs`. These data assets will be updated in real-time as your deployment is used in production. The data assets can then be used by your model monitors to monitor the performance of your model in production.

-## Next steps

-To learn how to monitor the performance of your models with the collected production inference data, see the following articles:

- - checkout: none

- - checkout: none

- azureml_job_name_from_submit_job: $[ dependencies.SubmitAzureMLJob.outputs['submit_azureml_job_task.AZUREML_JOB_NAME'] ]

-1. Find the feature you would like to try out and select the toggle next to it to enable or disable the feature.

-> Once a managed VNet workspace is configured to __allow only approved outbound__, the workspace cannot be reconfigured to __allow internet outbound__. Please keep this in mind when configuring managed VNet for your workspace.

-description: Monitor the performance of models deployed to production on Azure Machine Learning

-# Monitor performance of models deployed to production (preview)

-Once a machine learning model is in production, it's important to critically evaluate the inherent risks associated with it and identify blind spots that could adversely affect your business. Azure Machine Learning's model monitoring continuously tracks the performance of models in production by providing a broad view of monitoring signals and alerting you to potential issues. In this article, you learn to perform out-of box and advanced monitoring setup for models that are deployed to Azure Machine Learning online endpoints. You also learn to set up model monitoring for models that are deployed outside Azure Machine Learning or deployed to Azure Machine Learning batch endpoints.

-* Azure role-based access controls (Azure RBAC) are used to grant access to operations in Azure Machine Learning. To perform the steps in this article, your user account must be assigned the __owner__ or __contributor__ role for the Azure Machine Learning workspace, or a custom role allowing `Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*`. For more information, see [Manage access to an Azure Machine Learning workspace](how-to-assign-roles.md).

-# [Python](#tab/python)

-* Azure role-based access controls (Azure RBAC) are used to grant access to operations in Azure Machine Learning. To perform the steps in this article, your user account must be assigned the __owner__ or __contributor__ role for the Azure Machine Learning workspace, or a custom role allowing `Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*`. For more information, see [Manage access to an Azure Machine Learning workspace](how-to-assign-roles.md).

-* An Azure Machine Learning workspace and a compute instance. If you don't have these, use the steps in the [Quickstart: Create workspace resources](quickstart-create-resources.md) article to create them.

-* Azure role-based access controls (Azure RBAC) are used to grant access to operations in Azure Machine Learning. To perform the steps in this article, your user account must be assigned the __owner__ or __contributor__ role for the Azure Machine Learning workspace, or a custom role allowing `Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*`. For more information, see [Manage access to an Azure Machine Learning workspace](how-to-assign-roles.md).

-* For monitoring a model that is deployed to an Azure Machine Learning online endpoint (Managed Online Endpoint or Kubernetes Online Endpoint):

- * A model deployed to an Azure Machine Learning online endpoint. Both Managed Online Endpoint and Kubernetes Online Endpoint are supported. If you don't have a model deployed to an Azure Machine Learning online endpoint, see [Deploy and score a machine learning model by using an online endpoint](how-to-deploy-online-endpoints.md).

- * Data collection enabled for your model deployment. You can enable data collection during the deployment step for Azure Machine Learning online endpoints. For more information, see [Collect production data from models deployed to a real-time endpoint](how-to-collect-production-data.md).

-* For monitoring a model that is deployed to an Azure Machine Learning batch endpoint or deployed outside of Azure Machine Learning:

- * A way to collect production data and register it as an Azure Machine Learning data asset.

- * The registered Azure Machine Learning data asset is continuously updated for model monitoring.

- * (Recommended) The model should be registered in Azure Machine Learning workspace, for lineage tracking.

-> Model monitoring jobs are scheduled to run on serverless Spark compute pool with `Standard_E4s_v3` VM instance type support only. More VM instance type support will come in the future roadmap.

-## Set up out-of-the-box model monitoring

-If you deploy your model to production in an Azure Machine Learning online endpoint, Azure Machine Learning collects production inference data automatically and uses it for continuous monitoring.

-You can use Azure CLI, the Python SDK, or Azure Machine Learning studio for out-of-box setup of model monitoring. The out-of-box model monitoring provides following monitoring capabilities:

-* Azure Machine Learning will automatically detect the production inference dataset associated with a deployment to an Azure Machine Learning online endpoint and use the dataset for model monitoring.

-* The recent past production inference dataset is used as the comparison baseline dataset.

- * the recent past production inference dataset as the comparison baseline dataset.

-* A monitoring job is scheduled to run daily at 3:15am (for this example) to acquire monitoring signals and evaluate each metric result against its corresponding threshold. By default, when any threshold is exceeded, an alert email is sent to the user who set up the monitoring.

-## Configure feature importance

-For feature importance to be enabled with any of your signals (such as data drift or data quality,) you need to provide both the 'baseline_dataset' (typically training) dataset and 'target_column_name' fields.

-Azure Machine Learning model monitoring uses `az ml schedule` for model monitoring setup. You can create out-of-box model monitoring setup with the following CLI command and YAML definition:

-The following YAML contains the definition for out-of-the-box model monitoring.

-```yaml

-# out-of-box-monitoring.yaml

-$schema: http://azureml/sdk-2-0/Schedule.json

-name: fraud_detection_model_monitoring

-display_name: Fraud detection model monitoring

-description: Loan approval model monitoring setup with minimal configurations

-trigger:

- # perform model monitoring activity daily at 3:15am

- type: recurrence

- frequency: day #can be minute, hour, day, week, month

- interval: 1 # #every day

- schedule:

- hours: 3 # at 3am

- minutes: 15 # at 15 mins after 3am

-create_monitor:

- compute: # specify a spark compute for monitoring job

- instance_type: standard_e4s_v3

- runtime_version: 3.2

- monitoring_target:

- endpoint_deployment_id: azureml:fraud-detection-endpoint:fraud-detection-deployment

-```

-# [Python](#tab/python)

-You can use the following code to set up out-of-the-box model monitoring:

-from azure.identity import InteractiveBrowserCredential

- SparkResourceConfiguration,

-ml_client = MLClient(InteractiveBrowserCredential(), subscription_id, resource_group, workspace)

- runtime_version="3.2"

-monitoring_target = MonitoringTarget(endpoint_deployment_id="azureml:fraud_detection_endpoint:fraund_detection_deployment")

-monitor_definition = MonitorDefinition(compute=spark_compute, monitoring_target=monitoring_target)

-model_monitor = MonitorSchedule(name="fraud_detection_model_monitoring",

- trigger=recurrence_trigger,

- create_monitor=monitor_definition)

-1. Under **Manage**, select **Monitoring**.

-1. Select the model to monitor. The "Select deployment" dropdown list should be automatically populated if the model is deployed to an Azure Machine Learning online endpoint.

-1. Select the deployment in the **Select deployment** box.

-1. Select the training data to use as the comparison baseline in the **(Optional) Select training data** box.

-1. Enter a name for the monitoring in **Monitor name**.

-1. Select VM instance type for Spark pool in the **Select compute type** box.

-1. Select "Spark 3.2" for the **Spark runtime version**.

-1. Select your **Time zone** for monitoring the job run.

-1. Select "Recurrence" or "Cron expression" scheduling.

-1. For "Recurrence" scheduling, specify the repeat frequency, day, and time. For "Cron expression" scheduling, you would have to enter cron expression for monitoring run.

-1. Select **Finish**.

- :::image type="content" source="media/how-to-monitor-models/model-monitoring-basic-setup.png" alt-text="Screenshot of settings for model monitoring." lightbox="media/how-to-monitor-models/model-monitoring-basic-setup.png":::

-Azure Machine Learning provides many capabilities for continuous model monitoring. See [Capabilities of model monitoring](concept-model-monitoring.md#capabilities-of-model-monitoring) for a list of these capabilities. In many cases, you need to set up model monitoring with advanced monitoring capabilities. In the following example, we set up model monitoring with these capabilities:

-* Use of multiple monitoring signals for a broad view

-* Use of historical model training data or validation data as the comparison baseline dataset

-* Monitoring of top N features and individual features

-You can use Azure CLI, the Python SDK, or Azure Machine Learning studio for advanced setup of model monitoring.

-You can create advanced model monitoring setup with the following CLI command and YAML definition:

-```yaml

-# advanced-model-monitoring.yaml

-$schema: http://azureml/sdk-2-0/Schedule.json

-name: fraud_detection_model_monitoring

-display_name: Fraud detection model monitoring

-description: Fraud detection model monitoring with advanced configurations

-trigger:

- # perform model monitoring activity daily at 3:15am

- type: recurrence

- frequency: day #can be minute, hour, day, week, month

- interval: 1 # #every day

- schedule:

- hours: 3 # at 3am

- minutes: 15 # at 15 mins after 3am

-create_monitor:

- compute:

- instance_type: standard_e4s_v3

- runtime_version: 3.2

- monitoring_target:

- ml_task: classfiication

- endpoint_deployment_id: azureml:fraud-detection-endpoint:fraud-detection-deployment

-

- monitoring_signals:

- advanced_data_drift: # monitoring signal name, any user defined name works

- type: data_drift

- # target_dataset is optional. By default target dataset is the production inference data associated with Azure Machine Learning online endpoint

- reference_data:

- input_data:

- path: azureml:my_model_training_data:1 # use training data as comparison baseline

- type: mltable

- data_context: training

- target_column_name: fraud_detected

- features:

- top_n_feature_importance: 20 # monitor drift for top 20 features

- metric_thresholds:

- numerical:

- jensen_shannon_distance: 0.01

- categorical:

- pearsons_chi_squared_test: 0.02

- advanced_data_quality:

- type: data_quality

- # target_dataset is optional. By default target dataset is the production inference data associated with Azure Machine Learning online depoint

- reference_data:

- input_data:

- path: azureml:my_model_training_data:1

- type: mltable

- data_context: training

- features: # monitor data quality for 3 individual features only

- - feature_A

- - feature_B

- - feature_C

- metric_thresholds:

- numerical:

- null_value_rate: 0.05

- categorical:

- out_of_bounds_rate: 0.03

- feature_attribution_drift_signal:

- type: feature_attribution_drift

- # production_data: is not required input here

- # Please ensure Azure Machine Learning online endpoint is enabled to collected both model_inputs and model_outputs data

- # Azure Machine Learning model monitoring will automatically join both model_inputs and model_outputs data and used it for computation

- reference_data:

- input_data:

- path: azureml:my_model_training_data:1

- type: mltable

- data_context: training

- target_column_name: is_fraud

- metric_thresholds:

- normalized_discounted_cumulative_gain: 0.9

-

- alert_notification:

- emails:

- - abc@example.com

- - def@example.com

-```

-# [Python](#tab/python)

-You can use the following code for advanced model monitoring setup:

-from azure.identity import InteractiveBrowserCredential

- MonitorFeatureType,

- MonitorMetricName,

- FeatureAttributionDriftSignal,

- FeatureAttributionDriftMetricThreshold,

- MonitorInputData,

-ml_client = MLClient(InteractiveBrowserCredential(), subscription_id, resource_group, workspace)

- runtime_version="3.2"

- endpoint_deployment_id="azureml:fraud_detection_endpoint:fraund_detection_deployment"

-# training data to be used as baseline dataset

- path="azureml:my_model_training_data:1"

- target_column_name="is_fraud",

-features = MonitorFeatureFilter(top_n_feature_importance=20)

-features = ['feature_A', 'feature_B', 'feature_C']

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

-# Finally monitor definition

- name="fraud_detection_model_monitoring_complex",

-1. Complete the entires on the basic settings page as described in the [Set up out-of-box model monitoring](#set-up-out-of-the-box-model-monitoring) section.

-1. Select **More options** to open the advanced setup wizard.

-1. In the "Configure dataset" section, add a dataset to be used as the comparison baseline. We recommend using the model training data as the comparison baseline for data drift and data quality, and using the model validation data as the comparison baseline for prediction drift.

-1. Select **Next**.

-1. In the "Select monitoring signals" section, you see three monitoring signals already added if you have selected Azure Machine Learning online deployment earlier. These signals are: data drift, prediction drift, and data quality. All these prepopulated monitoring signals use recent past production data as the comparison baseline and use smart defaults for metrics and threshold.

- :::image type="content" source="media/how-to-monitor-models/model-monitoring-advanced-select-signals.png" alt-text="Screenshot showing how to select monitoring signals." lightbox="media/how-to-monitor-models/model-monitoring-advanced-select-signals.png":::

-1. In the data drift **Edit signal** window, configure following:

- 1. Change the baseline dataset to use training data.

- 1. Monitor drift for top 1-20 important features, or monitor drift for specific set of features.

- 1. Select your preferred metrics and set thresholds.

-1. Select **Save** to return to the "Select monitoring signals" section.

- :::image type="content" source="media/how-to-monitor-models/model-monitoring-advanced-config-edit-signal.png" alt-text="Screenshot showing how to edit signal settings for model monitoring." lightbox="media/how-to-monitor-models/model-monitoring-advanced-config-edit-signal.png":::

-1. Select **Add** to add another signal.

-1. In the "Add Signal" screen, select the **Feature Attribution Drift** panel.

-1. Enter a name for Feature Attribution Drift signal. Feature attribution drift currently requires a few additional steps:

-1. Configure your data assets for Feature Attribution Drift

- 1. In your model creation wizard, add your custom data asset from your [custom data collection](how-to-collect-production-data.md) called 'model inputs and outputs' which combines your joined model inputs and data assets as a separate data context.

-

- :::image type="content" source="media/how-to-monitor-models/feature-attribution-drift-inputs-outputs.png" alt-text="Screenshot showing how to configure a custom data asset with inputs and outputs joined." lightbox="media/how-to-monitor-models/feature-attribution-drift-inputs-outputs.png":::

-

- 1. Specify your training reference dataset that is used in the feature attribution drift component, and select your 'target column name' field, which is required to enable feature importance.

- 1. Confirm your parameters are correct

-1. Adjust the data window size according to your business case.

-1. Adjust the threshold according to your need.

-1. Select **Save** to return to the "Select monitoring signals" section.

-1. If you're done with editing or adding signals, select **Next**.

- :::image type="content" source="media/how-to-monitor-models/model-monitoring-advanced-config-add-signal.png" alt-text="Screenshot showing settings for adding signals." lightbox="media/how-to-monitor-models/model-monitoring-advanced-config-add-signal.png":::

-1. In the "Notification" screen, enable alert notification for each signal.

-1. Select **Next**.

- :::image type="content" source="media/how-to-monitor-models/model-monitoring-advanced-config-notification.png" alt-text="Screenshot of settings on the notification screen." lightbox="media/how-to-monitor-models/model-monitoring-advanced-config-notification.png":::

-1. Review your settings on the "Review monitoring settings" page.

-1. Select **Create** to confirm your settings for advanced model monitoring.

-## Set up model monitoring by bringing your own production data to Azure Machine Learning

-You can also set up model monitoring for models deployed to Azure Machine Learning batch endpoints or deployed outside of Azure Machine Learning. If you have production data but no deployment, you can use the data to perform continuous model monitoring. To monitor these models, you must meet the following requirements:

-* You have a way to collect production inference data from models deployed in production.

-* You can register the collected production inference data as an Azure Machine Learning data asset, and ensure continuous updates of the data.

-* You can provide a data preprocessing component and register it as an Azure Machine Learning component. The Azure Machine Learning component must have these input and output signatures:

- | input/output | signature name | type | description | example value |

- | input | data_window_start | literal, string | data window start-time in ISO8601 format. | 2023-05-01T04:31:57.012Z |

- | input | data_window_end | literal, string | data window end-time in ISO8601 format. | 2023-05-01T04:31:57.012Z |

- | input | input_data | uri_folder | The collected production inference data, which is registered as Azure Machine Learning data asset. | azureml:myproduction_inference_data:1 |

- | output | preprocessed_data | mltable | A tabular dataset, which matches a subset of baseline data schema. | |

-```yaml

-# model-monitoring-with-collected-data.yaml

-$schema: http://azureml/sdk-2-0/Schedule.json

-name: fraud_detection_model_monitoring

-display_name: Fraud detection model monitoring

-description: Fraud detection model monitoring with your own production data

-trigger:

- # perform model monitoring activity daily at 3:15am

- type: recurrence

- frequency: day #can be minute, hour, day, week, month

- interval: 1 # #every day

- schedule:

- hours: 3 # at 3am

- minutes: 15 # at 15 mins after 3am

-create_monitor:

- compute:

- instance_type: standard_e4s_v3

- runtime_version: 3.2

- monitoring_target:

- ml_task: classification

- endpoint_deployment_id: azureml:fraud-detection-endpoint:fraud-detection-deployment

-

- monitoring_signals:

- advanced_data_drift: # monitoring signal name, any user defined name works

- type: data_drift

- # define target dataset with your collected data

- production_data:

- input_data:

- path: azureml:my_production_inference_data_model_inputs:1 # your collected data is registered as Azure Machine Learning asset

- type: uri_folder

- data_context: model_inputs

- pre_processing_component: azureml:production_data_preprocessing:1

- reference_data:

- input_data:

- path: azureml:my_model_training_data:1 # use training data as comparison baseline

- type: mltable

- data_context: training

- target_column_name: is_fraud

- features:

- top_n_feature_importance: 20 # monitor drift for top 20 features

- metric_thresholds:

- numberical:

- jensen_shannon_distance: 0.01

- categorical:

- pearsons_chi_squared_test: 0.02

- advanced_prediction_drift: # monitoring signal name, any user defined name works

- type: prediction_drift

- # define target dataset with your collected data

- production_data:

- input_data:

- path: azureml:my_production_inference_data_model_outputs:1 # your collected data is registered as Azure Machine Learning asset

- type: uri_folder

- data_context: model_outputs

- pre_processing_component: azureml:production_data_preprocessing:1

- reference_data:

- input_data:

- path: azureml:my_model_validation_data:1 # use training data as comparison baseline

- type: mltable

- data_context: validation

- metric_thresholds:

- categorical:

- pearsons_chi_squared_test: 0.02

- advanced_data_quality:

- type: data_quality

- production_data:

- input_data:

- path: azureml:my_production_inference_data_model_inputs:1 # your collected data is registered as Azure Machine Learning asset

- type: uri_folder

- data_context: model_inputs

- pre_processing_component: azureml:production_data_preprocessing:1

- reference_data:

- input_data:

- path: azureml:my_model_training_data:1

- type: mltable

- data_context: training

- metric_thresholds:

- numerical:

- null_value_rate: 0.03

- categorical:

- out_of_bounds_rate: 0.03

- feature_attribution_drift_signal:

- type: feature_attribution_drift

- production_data:

- # using production_data collected outside of Azure Machine Learning

- - input_data:

- path: azureml:my_model_inputs:1

- type: uri_folder

- data_context: model_inputs

- data_column_names:

- correlation_id: correlation_id

- pre_processing_component: azureml:model_inputs_preprocessing

- data_window_size: P30D

- - input_data:

- path: azureml:my_model_outputs:1

- type: uri_folder

- data_context: model_outputs

- data_column_names:

- correlation_id: correlation_id

- prediction: is_fraund

- prediction_probability: is_fraund_probability

- pre_processing_component: azureml:model_outputs_preprocessing

- data_window_size: P30D

- reference_data:

- input_data:

- path: azureml:my_model_training_data:1

- type: mltable

- data_context: training

- target_column_name: is_fraud

- metric_thresholds:

- normalized_discounted_cumulative_gain: 0.9

-

- alert_notification:

- emails:

- - abc@example.com

- - def@example.com

-```

-# [Python](#tab/python)

-Once you've satisfied the previous requirements, you can set up model monitoring using the following Python code:

-# training data to be used as baseline dataset

-The studio currently doesn't support monitoring for models that are deployed outside of Azure Machine Learning. See the Azure CLI or Python tabs instead.

-With Azure Machine Learning model monitoring, you have the option to define your own custom signal and implement any metric of your choice to monitor your model. You can register this 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 have defined within your custom signal, just as it does for the prebuilt signals (data drift, prediction drift, data quality, & feature attribution drift). To get started with defining your own custom signal, you must meet the following requirement:

-* You must define your custom signal and register it as an Azure Machine Learning component. The Azure Machine Learning component must have these input and output signatures:

-The component input DataFrame should contain a `mltable` with the processed data from the preprocessing component and any number of literals, each representing an implemented metric as part of the custom signal component. For example, if you have implemented one metric, `std_deviation`, then you'll need an input for `std_deviation_threshold`. Generally, there should be one input per metric with the name {metric_name}_threshold.

- | signature name | type | description | example value |

- |||||

- | production_data | mltable | A tabular dataset, which matches a subset of baseline data schema. | |

- | std_deviation_threshold | literal, string | Respective threshold for the implemented metric. | 2 |

- | signature name | type | description |

- | signal_metrics | mltable | The ml table that contains the computed metrics. The schema is defined in the signal_metrics schema section in the next section. |

-The component output DataFrame should contain four columns: `group`, `metric_name`, `metric_value`, and `threshold_value`:

- | signature name | type | description | example value |

- | group | literal, string | Top level logical grouping to be applied to this custom metric. | TRANSACTIONAMOUNT |

- | metric_value | mltable | The value of the custom metric. | 44,896.082 |

- | threshold_value | | The threshold for the custom metric. | 2 |

-Here's an example output from a custom signal component computing the metric, `std_deviation`:

-An example custom signal component definition and metric computation code can be found in our GitHub repo at [https://github.com/Azure/azureml-examples/tree/main/cli/monitoring/components/custom_signal](https://github.com/Azure/azureml-examples/tree/main/cli/monitoring/components/custom_signal).

-Once you've satisfied the previous requirements, you can set up model monitoring with the following CLI command and YAML definition:

-The following YAML contains the definition for model monitoring with a custom signal. It's assumed that you have already created and registered your component with the custom signal definition to Azure Machine Learning. In this example, the `component_id` of the registered custom signal component is `azureml:my_custom_signal:1.0.0`:

- instance_type: "standard_e8s_v3"

- runtime_version: "3.2"

- trailing_window_size: P30D

- trailing_window_offset: P7D

-# [Python](#tab/python)

-## Next steps

-To run your R script, you'll use the `ml` extension for Azure CLI, also referred to as CLI v2. The `ml` command uses a YAML job definitions file. For more information about submitting jobs with `az ml`, see [Train models with Azure Machine Learning CLI](how-to-train-model.md?tabs=azurecli#4-submit-the-training-job).

-> To try [serverless compute](./how-to-use-serverless-compute.md), skip this step and proceed to [ 4. Submit the training job](#4-submit-the-training-job).

-### 4. Submit the training job

-When developing flows, you can not only use the built-in tools provided by prompt flow, but also develop your own custom tool. In this document, we guide you through the process of developing your own tool package, offering detailed steps and advice on how to utilize your creation.

-Your tool package should be a python package. To develop your custom tool, follow the steps **Create your own tool package** and **build and share the tool package** in [Create and Use Tool package](https://microsoft.github.io/promptflow/how-to-guides/develop-a-tool/create-and-use-tool-package.html). You can also [Add a tool icon](https://microsoft.github.io/promptflow/how-to-guides/develop-a-tool/add-a-tool-icon.html) and [Add Category and tags](https://microsoft.github.io/promptflow/how-to-guides/develop-a-tool/add-category-and-tags-for-tool.html) for your tool.

-To add the custom tool to your tool list, it's necessary to create a runtime, which is based on a customized environment where your custom tool is preinstalled. Here we use [my-tools-package](https://pypi.org/project/my-tools-package/) as an example to prepare the runtime.

-## Test from VS Code extension

-2. Go to terminal and install your tool package in conda environment of the extension. Assume your conda env name is `prompt-flow`.

- (prompt-flow) PS D:\projects\promptflow\tool-package-quickstart> pip install .\dist\my_tools_package-0.0.1-py3-none-any.whl

-## FAQ

-> Monitoring is currently in public preview. These previews are provided without a service-level agreement, and are not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.

-The following table provides an index of tools in prompt flow. If existing tools don't meet your requirements, you can [develop your own custom tool and make a tool package](https://microsoft.github.io/promptflow/how-to-guides/develop-a-tool/create-and-use-tool-package.html).

-To discover more custom tools developed by the open-source community, see [More custom tools](https://microsoft.github.io/promptflow/integrations/tools/https://docsupdatetracker.net/index.html).

-For the tools to use in the custom environment, see [Custom tool package creation and usage](../how-to-custom-tool-package-creation-and-usage.md#prepare-runtime) to prepare the runtime. Then the tools can be displayed in the tool list.

-| `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-your-own-production-data-to-azure-machine-learning). | | |

-| `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-your-own-production-data-to-azure-machine-learning). | | |

-| `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-your-own-production-data-to-azure-machine-learning). | | |

-| `reference_data.pre_processing_component` | String | Component ID in the format of `azureml:myPreprocessing@latest` for a registered component. **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-your-own-production-data-to-azure-machine-learning). | | |

-| `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-your-own-production-data-to-azure-machine-learning). | | |

-| `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-your-own-production-data-to-azure-machine-learning). | | |

-| `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-your-own-production-data-to-azure-machine-learning). | | |

-| `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-your-own-production-data-to-azure-machine-learning). | | |

-By default, Azure Database for MySQL flexible server enables automated backups of your entire server (encompassing all databases created) with a default 7-day retention period. You can also trigger a manual backup using On-Demand backup feature. The other way to manually take a backup is by using community tools such as mysqldump as documented [here](../concepts-migrate-dump-restore.md#dump-and-restore-using-mysqldump-utility) or mydumper as documented [here](../concepts-migrate-mydumper-myloader.md#create-a-backup-using-mydumper). If you wish to back up an Azure Database for MySQL flexible server instance to a Blob storage, refer to our tech community blog [Backup Azure Database for MySQL flexible server to a Blob Storage](https://techcommunity.microsoft.com/t5/azure-database-for-mysql/backup-azure-database-for-mysql-to-a-blob-storage/ba-p/803830).

-No, currently we only support a maximum of 35 days of automated backup retention. You can take manual backups and use that for long-term retention requirement.

-The first snapshot backup is scheduled immediately after a server is created. Snapshot backups are taken once daily. Transaction log backups occur every five minutes. Backup windows are inherently managed by Azure and can't be customized.

-All Azure Database for MySQL flexible server data, backups, and temporary files created during query execution are encrypted using AES 256-bit encryption. The storage encryption is always on and can't be disabled.

-Restoring a single/few database(s) or tables isn't supported. In case you want to restore specific databases, perform a Point in Time Restore and then extract the table(s) or database(s) needed.

-Yes. Backups are online operations and are snapshot-based. The snapshot operation only takes few seconds and doesn't interfere with production workloads, ensuring high availability of the server.

-No, backups are triggered internally as part of the managed service and have no bearing on the Managed Maintenance Window.

-Azure Database for MySQL flexible server automatically creates server backups and stores them in user-configured, locally redundant storage or in geo-redundant storage. These backup files can't be exported. The default backup retention period is seven days. You can optionally configure the database backup from 1 to 35 days.

-The best way to validate availability of successfully completed backups is to view the full-automated backups taken within the retention period in the Backup and Restore blade. If a backup fails, it isn't listed in the available backups list, and the backup service will try every 20 minutes to take a backup until a successful backup is taken. These backup failures are due to heavy transactional production loads on the server.

-In the Azure portal, under the Monitoring tab - Metrics section, you can find the [Backup Storage Used](./concepts-monitoring.md) metric, which can help you monitor the total backup usage.

-If you delete the server, all backups that belong to the server are also deleted and can't be recovered. To protect server resources post deployment from accidental deletion or unexpected changes, administrators can use [management locks](../../azure-resource-manager/management/lock-resources.md).

-If you restore a server, then it always results in a creation of a net new server that has been restored using original server's backups. The old backup from the original server is not copied over to the newly restored server and it remains with the original server. However, for the newly created server the first snapshot backup is scheduled immediately after a server is created and the service ensures daily automated backups are taken and stored as per configured server retention period.

-Azure Database for MySQL flexible server provides up to 100% of your provisioned server storage as backup storage at no added cost. Any more backup storage used is charged in GB per month as per the [pricing model](https://azure.microsoft.com/pricing/details/mysql/server/). Backup storage billing is also governed by the backup retention period selected and backup redundancy option chosen, apart from the transactional activity on the server, which impacts the total backup storage used directly.

-No new backups are performed for stopped servers. All older backups (within the retention window) at the time of stopping the server are retained until the server is restarted, post which backup retention for the active server is governed by its backup retention window.

-While your server instance is stopped, you're charged for provisioned storage (including Provisioned IOPS) and backup storage (backups stored within your specified retention window). Free backup storage is limited to the size of your provisioned database and only applies to active servers.

-Azure database for MySQL Flexible server protects your backup data by blocking any operations that could lead to loss of recovery points for the duration of the configured retention period. Backups taken during the retention period can only be read for the purpose of restoration and are deleted post retention period. Also, all backups in Azure Database for MySQL flexible server are encrypted using AES 256-bit encryption for the data stored at rest.

-The estimated time for the recovery of the server depends on several factors:

-For MySQL version 5.7, default value is 1 in Azure Database for MySQL flexible server. It is important to note that while it is possible to change the supported value to 2, reverting from 2 back to 1 is not allowed. Please contact our [support team](https://azure.microsoft.com/support/create-ticket/) for assistance in changing the default value.

-For [MySQl version 8.0+](https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html) lower_case_table_names can only be configured when initializing the server. [Learn more](https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html). Changing the lower_case_table_names setting after the server is initialized is prohibited. For MySQL version 8.0, default value is 1 in Azure Database for MySQL flexible server. Supported value for MySQL version 8.0 are 1 and 2 in Azure Database for MySQL flexible server. Please contact our [support team](https://azure.microsoft.com/support/create-ticket/) for assistance in changing the default value during server creation.

-If [`log_bin_trust_function_creators`] is set to OFF, if you try to create triggers you may get errors similar to *you do not have the SUPER privilege and binary logging is enabled (you might want to use the less safe `log_bin_trust_function_creators` variable)*.

-In Azure Database for MySQL flexible server, the `event_schedule` server parameter manages creating, scheduling, and running events, i.e., tasks that run according to a schedule, and they're run by a special event scheduler thread. When the `event_scheduler` parameter is set to ON, the event scheduler thread is listed as a daemon process in the output of SHOW PROCESSLIST. You can create and schedule events using the following SQL syntax:

-\** With the exception of 64,80, and 96 vCores, which has 504, 504 and 672 GiB of memory respectively.

-Therefore, while the Burstable compute tier offers significant cost and flexibility advantages for certain types of workloads, **it is not recommended for production workloads** that require consistent CPU performance. Note that the Burstable tier doesn't support functionality of creating [Read Replicas](./concepts-read-replicas.md) and [High availability](./concepts-high-availability.md) feature. For such workloads and features, other compute tiers, such as the General Purpose or Business Critical are more appropriate.

-For more information on the Azure's B-series CPU credit model, refer to the [B-series burstable instances](../../virtual-machines/sizes-b-series-burstable.md) and [B-series CPU credit model](../../virtual-machines/b-series-cpu-credit-model/b-series-cpu-credit-model.md#b-series-cpu-credit-model).

-[CPU Credit Remaining](./concepts-monitoring.md): This metric shows the number of CPU credits remaining for your instance. Keeping an eye on this metric can help you prevent your instance from degrading in performance due to exhausting its CPU credits.

-Here's an example to configure stop tasks for a Azure Database for MySQL flexible server instance.

-This article uses the Azure Marketplace offer for JBoss EAP to accelerate your journey to ARO. The offer automatically provisions a number of resources including an ARO cluster with a built-in OpenShift Container Registry (OCR), the JBoss EAP Operator, and optionally a container image including JBoss EAP and your application using Source-to-Image (S2I). To see the offer, visit the [Azure portal](https://aka.ms/eap-aro-portal). If you prefer manual step-by-step guidance for running JBoss EAP on ARO that doesn't utilize the automation enabled by the offer, see [Deploy a Java application with Red Hat JBoss Enterprise Application Platform (JBoss EAP) on an Azure Red Hat OpenShift 4 cluster](/azure/developer/java/ee/jboss-eap-on-aro).

- [](https://shell.azure.com)

- > [!NOTE]

- > You can also execute this guidance from a local developer command line with the Azure CLI installed. To learn how to install the Azure CLI, see [How to install the Azure CLI](/cli/azure/install-azure-cli).

- >

- > If you are using a local developer command line, you must install the `mysql` CLI. For instructions see [How To Install MySQL](https://www.digitalocean.com/community/tutorials/how-to-install-mysql-on-ubuntu-20-04).

-The Azure Marketplace offer you use in this article requires a Red Hat pull secret. This section shows you how to get a Red Hat pull secret for Azure Red Hat OpenShift. To learn about what a Red Hat pull secret is and why you need it, see the [Get a Red Hat pull secret](/azure/openshift/tutorial-create-cluster#get-a-red-hat-pull-secret-optional) section in [Tutorial: Create an Azure Red Hat OpenShift 4 cluster](/azure/openshift/tutorial-create-cluster).

-You've now created your Microsoft Entra application, service principal, and client secret.

-You've now created your Red Hat Container Registry service account.

-### Set environment variables in the Azure Cloud Shell

-Continuing in the Azure Cloud Shell, use the following command to set up some environment variables:

-ADMIN_PASSWORD=<mysql-admin-password>

-It's a good idea to save the fully filled out name/value pairs in a text file, in case the Azure Cloud Shell times out before you're done executing the commands. That way, you can paste them into a new instance of the Cloud Shell and easily continue.

-These name/value pairs are essentially "secrets". For a production-ready way to secure Azure Red Hat OpenShift, including secret management, see [Security for the Azure Red Hat OpenShift landing zone accelerator](/azure/cloud-adoption-framework/scenarios/app-platform/azure-red-hat-openshift/security).

-The steps in this section show you how to verify that the deployment has successfully completed.

-1. Open Azure Cloud Shell, paste the value from the **cmdToGetKubeadminCredentials** field, and execute it. You see the admin account and credential for signing in to the OpenShift cluster console portal. The following example shows an admin account:

-1. In the Azure Cloud Shell, use the following commands to download the latest OpenShift 4 CLI for GNU/Linux. If running on an OS other than GNU/Linux, download the appropriate binary for that OS.

-1. Paste the value from the **cmdToLoginWithKubeadmin** field into the Azure Cloud Shell, and execute it. You should see the `login successful` message and the project you're using. The following content is an example of the command to connect to the OpenShift cluster using the OpenShift CLI.

-1. In the Azure Cloud Shell, run the following commands to create a project, apply a permission to enable S2I to work, image the pull secret, and link the secret to the relative service accounts in the project for image pulling. Disregard the git warning about "'detached HEAD' state".

-Data Product operators can choose which data types to use and the data retention period for each data type.

-## Availability

-Azure Payment HSM is currently available in the following regions:

-## Prerequisites

-Azure Payment HSM customers must have:

-## Cost

-The HSM devices will be charged based on the [Azure Payment HSM pricing page](https://azure.microsoft.com/pricing/details/payment-hsm/). All other Azure resources for networking and virtual machines will incur regular Azure costs too.

-## payShield customization considerations

-If you are using payShield on-premises today with a custom firmware, a porting exercise is required to update the firmware to a version compatible with the Azure deployment. Please contact your Thales account manager to request a quote.

-Ensure that the following information is provided:

-## Support

-For details on Azure Payment HSM prerequisites, support channels, and division of support responsibility between Microsoft, Thales, and the customer, see the [Azure Payment HSM service support guide](support-guide.md).

-Payment HSM devices are a variation of [Dedicated HSM](../dedicated-hsm/index.yml) devices, with more advanced cryptographic modules and features; for example, a payment HSM never decrypts the PIN value in transit.

-> Azure Payment HSM a highly specialized service. We highly recommend that you review the [Azure Payment HSM pricing page](https://azure.microsoft.com/services/payment-hsm/) and [Getting started with Azure Payment HSM](getting-started.md#support).

-Microsoft will work with Thales to ensure that customers meet the prerequisites before starting the onboarding process.

-The HSM base firmware installed is Thales payShield10K base software version 1.4a 1.8.3 with the Premium Package license. Versions below 1.4a 1.8.3. are not supported. Customers must ensure that they only upgrade to a firmware version that meets their compliance requirements.

-The Premium Package license included in Azure payment HSM features:

-Customers are responsible for applying payShield security patches and upgrading payShield firmware for their provisioned HSMs, as needed. If customers have questions or require assistance, they should work with Thales support.

-Microsoft is responsible for applying payShield security patches to unallocated HSMs.

-Microsoft will provide support for hardware issues, networking issues, and provisioning issues. Enterprise customers should contact their CSAM to find out details of their support contract .

-> [!NOTE]

-> Azure Database for PostgreSQL flexible server support for Private Endpoints in Preview requires enablement of [**Azure Database for PostgreSQL flexible server Private Endpoint capability** preview feature in your subscription](../../azure-resource-manager/management/preview-features.md).

-> Only **after preview feature is enabled** you can create servers which are PE capable, i.e. can be networked using Private Link.

-description: This article describes the resource scaling in Azure Database for PostgreSQL - Flexible Server.

-# Scaling resources in Azure Database for PostgreSQL - Flexible Server

-Azure Database for PostgreSQL flexible server supports both **vertical** and **horizontal** scaling options.

-You can scale **vertically** by adding more resources to the Azure Database for PostgreSQL flexible server instance, such as increasing the instance-assigned number of CPUs and memory. Network throughput of your instance depends on the values you choose for CPU and memory. Once an Azure Database for PostgreSQL flexible server instance is created, you can independently change the CPU (vCores), the amount of storage, and the backup retention period. The number of vCores can be scaled up or down. However, the storage size however can only be increased. In addition, you can scale the backup retention period, up or down, from 7 to 35 days. The resources can be scaled using multiple tools, for instance [Azure portal](./quickstart-create-server-portal.md) or the [Azure CLI](./quickstart-create-server-cli.md).

-> [!NOTE]

-You can scale **horizontally** by creating [read replicas](./concepts-read-replicas.md). Read replicas let you scale your read workloads onto separate Azure Database for PostgreSQL flexible server instances, without affecting the performance and availability of the primary instance.

-When you change the number of vCores or the compute tier, the instance is restarted for the new server type to take effect. During this time the system is switching over to the new server type, no new connections can be established, and all uncommitted transactions are rolled back. The overall time it takes to restart your server depends on the crash recovery process and database activity at the time of the restart. Restart typically takes a minute or less, but it can be higher and can take several minutes, depending on transactional activity at the time the restart was initiated.

-If your application is sensitive to loss of in-flight transactions that may occur during compute scaling, we recommend implementing transaction [retry pattern](../single-server/concepts-connectivity.md#handling-transient-errors).

-## Near-zero downtime scaling

-Near-zero downtime scaling is a feature designed to minimize downtime when modifying storage and compute tiers. If you modify the number of vCores or change the compute tier, the server undergoes a restart to apply the new configuration. During this transition to the new server, no new connections can be established. Typically, this process with regular scaling could take anywhere between 2 to 10 minutes. However, with the new 'Near-zero downtime' scaling feature this duration is reduced to less than 30 seconds. This significant reduction in downtime during scaling resources greatly improves the overall availability of your database instance.

-When updating your Azure Database for PostgreSQL flexible server instance in scaling scenarios, we create a new copy of your server (VM) with the updated configuration, synchronize it with your current one, briefly switch to the new copy with a 30-second interruption, and retire the old server, all at no extra cost to you. This process allows for seamless updates while minimizing downtime and ensuring cost-efficiency. This scaling process is triggered when changes are made to the storage and compute tiers, and the experience remains consistent for both HA and non-HA servers. This feature is enabled in all Azure regions and there's **no customer action required** to use this capability.

-> Near-zero downtime scaling process is the _default_ operation. However, in cases where the following limitations are encountered, the system switches to regular scaling, which involves more downtime compared to the near-zero downtime scaling.

-### Precise Downtime Expectations

-* **Downtime Duration**: In most cases, the downtime ranges from 10 to 30 seconds.

-* **Additional Considerations**: After a scaling event, there's an inherent DNS `Time-To-Live` (TTL) period of approximately 30 seconds. This period isn't directly controlled by the scaling process but is a standard part of DNS behavior. So, from an application perspective, the total downtime experienced during scaling could be in the range of **40 to 60 seconds**.

-#### Considerations and limitations

-description: Describes the server parameters in Azure Database for PostgreSQL - Flexible Server.

-Azure Database for PostgreSQL flexible server provides a subset of configurable parameters for each server. For more information on Postgres parameters, see the [PostgreSQL documentation](https://www.postgresql.org/docs/current/config-setting.html).

-## An overview of PostgreSQL parameters

-Azure Database for PostgreSQL server is pre-configured with optimal default values for each parameter on creation. Static parameters require a server restart. Further parameters that require superuser access cannot be configured by the user.

-In order to review which parameters are available to view or to modify, we recommend going into the Azure portal, and to the Server Parameters page. You can also configure parameters on a per-user or per-database basis using `ALTER DATABASE` or `ALTER ROLE` commands.

->[!NOTE]

-> Since Azure Database for PostgreSQL is a managed database service, users are not provided host or OS access to view or modify configuration files such as `postgresql.conf`. The content of the file is automatically updated based on parameter changes in the Server Parameters page.

-Here's the list of some of the parameters:

- | Parameter Name | Description |

-|-|--|

-| **max_connections** | You can tune max_connections on Azure Database for PostgreSQL flexible server, where it can be set to 5000 connections. See the [limits documentation](concepts-limits.md) for more details. Although it is not the best practice to set this value higher than several hundreds. See [Postgres Wiki](https://wiki.postgresql.org/wiki/Number_Of_Database_Connections) for more details. If you are considering higher values, consider using [connection pooling](concepts-pgbouncer.md) instead. |

-| **shared_buffers** | The 'shared_buffers' setting changes depending on the selected SKU (SKU determines the memory available). General Purpose servers have 2 GB shared_buffers for 2 vCores; Memory Optimized servers have 4 GB shared_buffers for 2 vCores. The shared_buffers setting scales linearly (approximately) as vCores increase in a tier. |

-| **shared_preload_libraries** | This parameter is available for configuration with a predefined set of supported extensions. We always load the `azure` extension (used for maintenance tasks), and the `pg_stat_statements` extension (you can use the pg_stat_statements.track parameter to control whether the extension is active). |

-| **connection_throttling** | You can enable or disable temporary connection throttling per IP for too many invalid password login failures. |

- | **work_mem** | This parameter specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files. Increasing this parameter value can help Azure Database for PostgreSQL flexible server perform larger in-memory scans instead of spilling to disk, which is faster. This configuration is beneficial if your workload contains few queries but with many complex sorting tasks, and you have ample available memory. Be careful however, as one complex query may have number of sort, hash operations running concurrently. Each one of those operations uses as much memory as it value allows before it starts writing to disk based temporary files. Therefore on a relatively busy system total memory usage is many times of individual work_mem parameter. If you do decide to tune this value globally, you can use formula Total RAM * 0.25 / max_connections as initial value. Azure Database for PostgreSQL flexible server supports range of 4096-2097152 kilobytes for this parameter. |

-| **effective_cache_size** | The effective_cache_size parameter estimates how much memory is available for disk caching by the operating system and within the database shared_buffers itself. This parameter is just a planner "hint" and does not allocate or reserve any memory. Index scans are most likely to be used against higher values; otherwise, sequential scans are used if the value is low. Recommendations are to set effective_cache_size at 50%-75% of the machineΓÇÖs total RAM. |

-| **maintenance_work_mem** | The maintenance_work_mem parameter basically provides the maximum amount of memory to be used by maintenance operations like vacuum, create index, and alter table add foreign key operations. Default value for that parameter is 64 KB. ItΓÇÖs recommended to set this value higher than work_mem. |

-| **effective_io_concurrency** | Sets the number of concurrent disk I/O operations that Azure Database for PostgreSQL flexible server expects can be executed simultaneously. Raising this value increases the number of I/O operations that any individual Azure Database for PostgreSQL flexible server session attempts to initiate in parallel. The allowed range is 1 to 1000, or zero to disable issuance of asynchronous I/O requests. Currently, this setting only affects bitmap heap scans. |

- |**require_secure_transport** | If your application doesn't support SSL connectivity to the server, you can optionally disable secured transport from your client by turning `OFF` this parameter value. |

- |**log_connections** | This parameter may be read-only, as on Azure Database for PostgreSQL flexible server all connections are logged and intercepted to make sure connections are coming in from right sources for security reasons. |

-|**log_disconnections** | This parameter may be read-only, as on Azure Database for PostgreSQL flexible server all disconnections are logged. |

->[!NOTE]

-> As you scale Azure Database for PostgreSQL flexible server SKUs up or down, affecting available memory to the server, you may wish to tune your memory global parameters, such as `work_mem` or `effective_cache_size` accordingly based on information shared in the article.

-

-description: This article describes how to download server logs using Azure CLI.

-# List and download Azure Database for PostgreSQL - Flexible Server logs by using the Azure CLI

-This article shows you how to list and download Azure Database for PostgreSQL flexible server logs using Azure CLI.

-This article requires that you're running the Azure CLI version 2.39.0 or later locally. To see the version installed, run the `az --version` command. If you need to install or upgrade, see [Install Azure CLI](/cli/azure/install-azure-cli).

-You need to sign-in to your account using the [az login](/cli/azure/reference-index#az-login) command. Note the **id** property, which refers to **Subscription ID** for your Azure account.

-Select the specific subscription under your account using [az account set](/cli/azure/account) command. Make a note of the **id** value from the **az login** output to use as the value for **subscription** argument in the command. If you have multiple subscriptions, choose the appropriate subscription in which the resource should be billed. To get all your subscription, use [az account list](/cli/azure/account#az-account-list).

-## List server logs using Azure CLI

-Once you're configured the prerequisites and connected to your required subscription. You can list the server logs from your Azure Database for PostgreSQL flexible server instance by using the following command.

-> [!Note]

-> You can configure your server logs in the same way as above using the [Server Parameters](./howto-configure-server-parameters-using-portal.md), setting the appropriate values for these parameters: _logfiles.download_enable_ to ON to enable this feature, and _logfiles.retention_days_ to define retention in days. Initially, server logs occupy data disk space for about an hour before moving to backup storage for the set retention period.

-Here are the details for the above command

-|**LastModifiedTime** |**Name** |**ResourceGroup**|**SizeInKb**|**TypePropertiesType**|**Url** |

-The output table here lists `LastModifiedTime`, `Name`, `ResourceGroup`, `SizeInKb` and `Download Url` of the Server Logs.

-By default `LastModifiedTime` is set to 72 hours, for listing files older than 72 hours, use flag `--file-last-written <Time:HH>`

-## Download server logs using Azure CLI

-# Migration tool - Azure database for PostgreSQL Single Server to Flexible Server

-| Single to Flex Migration tool (**Recommended**) | Offline | - Managed migration service.<br />- No complex setup/pre-requisites required<br />- Simple to use portal-based migration experience<br />- Fast offline migration tool<br />- No limitations in terms of size of databases it can handle. | Downtime to applications. |

-| Azure DMS | Online | - Minimal downtime to your application<br />- Free of cost | - Complex setup<br />- High chances of migration failures<br />- Can't handle database of sizes > 1 TB<br />- Can't handle write-intensive workload |

-The next section of the document gives an overview of the Single to Flex Migration tool, its implementation, limitations, and the experience that makes it the recommended tool to perform migrations from single to flexible server.

-We noticed many migrations fail due to setup issues on source and target server. Most of the issues can be categorized into the following buckets:

-* Issues related to authentication/permissions for the migration user on source and target server.

-* [Prerequisites](#migration-prerequisites) not being taken care of, before running the migration.

-* Unsupported features/configurations between the source and target.

-* **Validate** - Use this option to check your server and database readiness for migration to the target. **This option will not start data migration and will not require any downtime to your servers.**

-The result of the Validate option can be

- - **Succeeded** - No issues were found and you can plan for the migration

- - **Failed** - There were errors found during validation, which can fail the migration. Go through the list of errors along with their suggested workarounds and take corrective measures before planning the migration.

- - **Warning** - Warnings are informative messages that you need to keep in mind while planning the migration.

- Plan your migrations better by performing pre-migration validations in advance to know the potential issues you might encounter while performing migrations.

-* **Migrate** - Use this option to kickstart the migration without going through validation process. It's recommended to perform validation before triggering a migration to increase the chances for a successful migration. Once validation is done, you can use this option to start the migration process.

-* **Validate and Migrate** - In this option, validations are performed and then migration gets triggered if all checks are in **succeeded** or **warning** state. Validation failures don't start the migration between source and target servers.

-> This functionality is enabled by default for flexible servers in all Azure public regions. It will be enabled for flexible servers in gov clouds and China regions soon.

-### Getting started

-The migration tool automatically allowlists all extensions used by your single server databases on your flexible server except for the ones whose libraries need to be loaded at the server start.

- FROM

- pg_roles r

- JOIN pg_auth_members am ON r.oid = am.member

- JOIN pg_roles m ON am.roleid = m.oid

- WHERE

- m.rolname IN (

- 'azure_ad_admin',

- 'azure_ad_user',

- 'azure_ad_mfa'

- );

-```

-## Next steps

-4. Select the **Migrate from Single Server** button to start a migration from Single Server to Flexible Server. If this is the first time you're using the migration tool, an empty grid appears with a prompt to begin your first migration.

-Select the **Next** button.

-After filling out all the fields, select the **Next** button.

-The **Target** tab displays metadata for the Flexible Server target, like subscription name, resource group, server name, location, and PostgreSQL version.

-For **Server admin login name**, the tab displays the admin username used during the creation of the Flexible Server target. Enter the corresponding password for the admin user.

-Select the **Next** button.

-Under this tab, there's a list of user databases inside the Single Server. You can select and migrate up to eight databases in a single migration attempt. If there are more than eight user databases, the migration process is repeated between the source and target servers for the next set of databases.

-### Review

-The **Review** tab summarizes all the details for creating the validation or migration. Review the details and click on the start button.

-The grid that displays the migrations has these columns: **Name**, **Status**, **Source DB server**, **Resource group**, **Region**, **Databases**, and **Start time**. The entries are displayed in the descending order of the start time with the most recent entry on the top.

-The validation grid has the following columns

-The validation moves to **Validation Failed** state if there are any errors in the validation. Click on the **Finding** in the grid whose status is **Failed** and a fan-out pane gives the details and the corrective action you should take to avoid this error.

-You can see the results of validation under the **Validation** tab and monitor the migration under the **Migration** tab.

-> Support for **Online** migrations is currently available in UK South, South Africa North, UAE North, and all regions across Asia and Australia.

- > [!NOTE]

- > Only the first shared access policy for the event hub will be used by this feature. Any additional shared access policies will be ignored.

-UE usage monitoring can be configured during [site creation](create-a-site.md) or at a later stage by [modifying the packet core](modify-packet-core.md).

-Once Event Hubs is receiving data from your AP5GC deployment you can write an application, using SDKs such as [.NET](/azure/event-hubs/event-hubs-dotnet-standard-getstarted-send?tabs=passwordless%2Croles-azure-portal), to consume event data and produce useful metric data.

-description: Learn how Azure Route Server works in a dual-homed network.

-## Next steps

-description: Learn how to observe the application of Azure Spring Apps.

-# Optimize application observability for Azure Spring Apps

-> [!NOTE]

-> Azure Spring Apps is the new name for the Azure Spring Cloud service. Although the service has a new name, you'll see the old name in some places for a while as we work to update assets such as screenshots, videos, and diagrams.

-**This article applies to:** ✔️ Java ❌ C#

-**This article applies to:** <br>

-❌ Standard consumption and dedicated (Preview) ✔️ Basic/Standard ❌ Enterprise

-This article shows you how to observe your production applications deployed on Azure Spring Apps and diagnose and investigate production issues. Observability is the ability to collect insights, analytics, and actionable intelligence through the logs, metrics, traces, and alerts.

-To find out if your applications meet expectations and to discover and predict issues in all applications, focus on the following areas:

-This article uses the well-known [PetClinic](https://github.com/azure-samples/spring-petclinic-microservices) sample app as the production application. For more information on how to deploy PetClinic to Azure Spring Apps and use MySQL as the persistent store, see the following articles:

-Log Analytics and Application Insights are deeply integrated with Azure Spring Apps. You can use Log Analytics to diagnose your application with various log queries and use Application Insights to investigate production issues. For more information, see the following articles:

-## Prerequisites

-## Query logs to diagnose an application problem

-If you encounter production issues, you need to do a root cause analysis. Finding logs is an important part of this analysis, especially for distributed applications with logs spread across multiple applications. The trace data collected by Application Insights can help you find the log information for all related links, including the exception stack information.

-This section explains how to use Log Analytics to query the application logs and use Application Insights to investigate request failures. For more information, see the following articles:

-### Log queries

-This section explains how to query application logs from the `AppPlatformLogsforSpring` table hosted by Azure Spring Apps. You can use the [Kusto Query Language](/azure/data-explorer/kusto/query/) to customize your queries for application logs.

-To see the built-in example query statements or to write your own queries, open the Azure Spring Apps instance and go to the **Logs** menu.

-#### Show the application logs that contain the "error" or "exception" terms

-To see the application logs containing the terms "error" or "exception", select **Alerts** on the **Queries** page, and then select **Run** in the **Show the application logs which contain the "error" or "exception" terms** section.

-The following query shows the application logs from the last hour that contains the terms "error" or "exception". You can customize the query with any keyword you want to search for.

-```sql

-AppPlatformLogsforSpring

-| where TimeGenerated > ago(1h)

-| where Log contains "error" or Log contains "exception"

-| project TimeGenerated , ServiceName , AppName , InstanceName , Log , _ResourceId

-```

-#### Show the error and exception number of each application

-To see the error and exception number of an application, select **Alerts** on the **Queries** page, and then select **Run** in the **Show the error and exception number of each application** section.

-The following query shows a pie chart of the number of the logs in the last 24 hours that contain the terms "error" or "exception". To view the results in a table format, select **Result**.

-```sql

-AppPlatformLogsforSpring

-| where TimeGenerated > ago(24h)

-| where Log contains "error" or Log contains "exception"

-| extend FullAppName = strcat(ServiceName, "/", AppName)

-| summarize count_per_app = count() by FullAppName, ServiceName, AppName, _ResourceId

-| sort by count_per_app desc

-| render piechart

-```

-#### Query the customers service log with a key word

-Use the following query to see a list of logs in the `customers-service` app that contain the term "root cause". Update the query to use the keyword that you're looking for.

-```sql

-AppPlatformLogsforSpring

-| where AppName == "customers-service"

-| where Log contains "root cause"

-| project-keep InstanceName, Log

-```

-### Investigate request failures

-Use the following steps to investigate request failures in the application cluster and to view the failed request list and specific examples of the failed requests:

-1. Go to the Azure Spring Apps instance overview page.

-1. On the navigation menu, select **Application Insights** to go to the Application Insights overview page. Then, select **Failures**.

- :::image type="content" source="media/application-observability/application-insights-failures.png" alt-text="Screenshot of the Azure portal that shows the Application Insights Failures page." lightbox="media/application-observability/application-insights-failures.png":::

-1. On the **Failure** page, select the `PUT` operation that has the most failed requests count, select **1 Samples** to go into the details, and then select the suggested sample.

- :::image type="content" source="media/application-observability/application-insights-failure-suggested-sample.png" alt-text="Screenshot of the Azure portal that shows the Select a sample operation pane with the suggested failure sample." lightbox="media/application-observability/application-insights-failure-suggested-sample.png":::

-1. Go to the **End-to-end transaction details** page to view the full call stack in the right panel.

- :::image type="content" source="media/application-observability/application-insights-e2e-exception.png" alt-text="Screenshot of the Azure portal that shows the End-to-end transaction details page with Application Insights failures." lightbox="media/application-observability/application-insights-e2e-exception.png":::

-## Improve the application performance using Application Insights

-If there's a performance issue, the trace data collected by Application Insights can help find the log information of all relevant links, including the execution time of each link, to help find the location of the performance bottleneck.

-To use Application Insights to investigate the performance issues, use the following steps:

-1. Go to the Azure Spring Apps instance overview page.

-1. On the navigation menu, select **Application Insights** to go to the Application Insights overview page. Then, select **Performance**.

- :::image type="content" source="media/application-observability/application-insights-performance.png" alt-text="Screenshot of the Azure portal that shows the Application Insights Performance page." lightbox="media/application-observability/application-insights-performance.png":::

-1. On the **Performance** page, select the slowest `GET /api/gateway/owners/{ownerId}` operation, select **3 Samples** to go into the details, and then select the suggested sample.

- :::image type="content" source="media/application-observability/application-insights-performance-suggested-sample.png" alt-text="Screenshot of the Azure portal that shows the Select a sample operation pane with the suggested performance sample." lightbox="media/application-observability/application-insights-performance-suggested-sample.png":::

-1. Go to the **End-to-end transaction details** page to view the full call stack in the right panel.

- :::image type="content" source="media/application-observability/application-insights-e2e-performance.png" alt-text="Screenshot of the Azure portal that shows the End-to-end transaction details page with the Application Insights performance issue." lightbox="media/application-observability/application-insights-e2e-performance.png":::

-## Next steps

-> [!div class="nextstepaction"]

-> [Set up a staging environment](../spring-apps/how-to-staging-environment.md)

-> [!div class="nextstepaction"]

-> [Map an existing custom domain to Azure Spring Apps](./how-to-custom-domain.md)

-> [!div class="nextstepaction"]

-> [Use TLS/SSL certificates](./how-to-use-tls-certificate.md)