Azure App Service Logging: How to Monitor Your Web Apps in Real-Time
As a developer, having visibility into the behavior of your applications is crucial to maintaining the reliability and performance of your software. Luckily, Azure App Service provides two powerful logging features to help you monitor your web apps in real-time: App Service Logs and Log Stream. In this blog post, we'll explore how to configure these features for both Windows and Linux Web Apps in Azure App Service.Announcing App Service Environment v3 GA
We are happy to announce the GA of App Service Environment v3 (ASEv3) along with Isolated V2. The ASEv3 was developed in response to customer feedback and has many improvements over the earlier versions while still providing an isolated single tenant web application hosting platform. As part of the Azure App Service, the ASEv3 provides a PaaS experience to host your Windows or Linux applications. You can deploy Windows or Linux applications as code and Microsoft will manage the OS your applications run in. If you want greater control over your app, you have the ability to host Linux containers as well. Just like with earlier versions, the ASEv3 deploys into a subnet in one of your Azure Virtual Networks (VNets). You can choose to deploy the ASE with an internal VIP in your VNet or with an external VIP that faces the internet. Apps that are deployed into an ASEv3 can access resources within the same VNet without any additional configuration. The inbound and outbound traffic to your apps can be controlled completely with Network Security Groups (NSGs) or any supported type of routes.
How to connect Azure SQL database from Python Function App using managed identity or access token
This blog will demonstrate on how to connect Azure SQL database from Python Function App using managed identity or access token. If you are looking for how to implement it in Windows App Service, you may refer to this post: https://techcommunity.microsoft.com/t5/apps-on-azure-blog/how-to-connect-azure-sql-database-from-azure-app-service-windows/ba-p/2873397. Note that Azure Active Directory managed identity authentication method was added in ODBC Driver since version 17.3.1.1 for both system-assigned and user-assigned identities. In Azure blessed image for Python Function, the ODBC Driver version is 17.8. Which makes it possible to leverage this feature in Linux App Service. Briefly, this post will provide you a step to step guidance with sample code and introduction on the authentication workflow. Steps: 1. Create a Linux Python Function App from portal 2. Set up the managed identity in the new Function App by enable Identity and saving from portal. It will generate an Object(principal) ID for you automatically. 3. Assign role in Azure SQL database. Search for your own account and save as admin. Note: Alternatively, you can search for the function app's name and set it as admin, then that function app would own admin permission on the database and you can skip step 4 and 5 as well. 4. Got to Query editor in database and be sure to login using your account set in previous step rather than username and password. Or step 5 will fail with below exception. "Failed to execute query. Error: Principal 'xxxx' could not be created. Only connections established with Active Directory accounts can create other Active Directory users." 5. Run below queries to create user for the function app and alter roles. You can choose to alter part of these roles per your demand. CREATE USER "yourfunctionappname" FROM EXTERNAL PROVIDER; ALTER ROLE db_datareader ADD MEMBER "yourfunctionappname" ALTER ROLE db_datawriter ADD MEMBER "yourfunctionappname" ALTER ROLE db_ddladmin ADD MEMBER "yourfunctionappname" 6. Leverage below sample code to build your own project and deploy to the function app. Sample Code: Below is the sample code on how to use Azure access token when run it from local and use managed identity when run in Function app. The token part needs to be replaced with your own. Basically, it is using "pyodbc.connect(connection_string+';Authentication=ActiveDirectoryMsi')" to authenticate with managed identity. Also, "MSI_SECRET" is used to tell if we are running it from local or function app, it will be created automatically as environment variable when the function app is enabled with Managed Identity. The complete demo project can be found from: https://github.com/kevin808/azure-function-pyodbc-MI import logging import azure.functions as func import os import pyodbc import struct def main(req: func.HttpRequest) -> func.HttpResponse: logging.info('Python HTTP trigger function processed a request.') server="your-sqlserver.database.windows.net" database="your_db" driver="{ODBC Driver 17 for SQL Server}" query="SELECT * FROM dbo.users" # Optional to use username and password for authentication # username = 'name' # password = 'pass' db_token = '' connection_string = 'DRIVER='+driver+';SERVER='+server+';DATABASE='+database #When MSI is enabled if os.getenv("MSI_SECRET"): conn = pyodbc.connect(connection_string+';Authentication=ActiveDirectoryMsi') #Used when run from local else: SQL_COPT_SS_ACCESS_TOKEN = 1256 exptoken = b'' for i in bytes(db_token, "UTF-8"): exptoken += bytes({i}) exptoken += bytes(1) tokenstruct = struct.pack("=i", len(exptoken)) + exptoken conn = pyodbc.connect(connection_string, attrs_before = { SQL_COPT_SS_ACCESS_TOKEN:tokenstruct }) # Uncomment below line when use username and password for authentication # conn = pyodbc.connect('DRIVER='+driver+';SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password) cursor = conn.cursor() cursor.execute(query) row = cursor.fetchone() while row: print(row[0]) row = cursor.fetchone() return func.HttpResponse( 'Success', status_code=200 ) Workflow: Below are the workflow in these two authentication ways, with them in mind, we can understand what happened under the hood. Managed Identity: When we enable the managed identify for function app, a service principal will be generated automatically for it, then it follows the same steps as below to authenticate in database. Function App with managed identify -> send request to database with service principal -> database check the corresponding database user and its permission -> Pass authentication. Access Token: The access toke can be generated by executing ‘az account get-access-token --resource=https://database.windows.net/ --query accessToken’ from local, we then hold this token to authenticate. Please note that the default lifetime for the token is one hour, which means we would need to retrieve it again when it expires. az login -> az account get-access-token -> local function use token to authenticate in SQL database -> DB check if the database user exists and if the permissions granted -> Pass authentication. Thanks for reading. I hope you enjoy it.
Restore(Undelete) Deleted Web Apps
We can restore a delete web app, If the WebApp was deleted in last 30 days. If the WebApp was not hosted on Free or Shared sku. If the WebApp was not hosted on App Service Environment (ASE). If it's not a Function App hosted on Consumption or Elastic Premium plans.
Issues you may meet when upgrading Azure function app to V4
This blog will talk about some common issues you may meet when you try to upgrade your Azure function from older runtime version to newer (eg. ~4) and the causes/resolutions. Public Doc: Blog Function v4 VS v3: https://techcommunity.microsoft.com/t5/apps-on-azure-blog/azure-functions-v4-versus-v3/ba-p/3276055 Migrate from 3.x to 4.x: https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions?tabs=in-process%2Cv4&pivots=programming-language-powershell#migrating-from-3x-to-4x Migrate from 2.x to 3.x: https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions?tabs=in-process%2Cv4&pivots=programming-language-powershell#migrating-from-2x-to-3x Known issues: https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions?tabs=in-process%2Cv4&pivots=programming-language-powershell#runtime [Issue 1] Runtime warning message on portal To upgrade your function App, you set the FUNCTIONS_EXTENSION_VERSION to "~4". You may observe below warning message and the runtime version got set to "custom" rather than "~4". "Your app is pinned to an unsupported runtime version for 'xxx'. For better performance, we recommend using one of our supported versions instead: xxx." Troubleshooting: 1. Access https://resources.azure.com/ to check the runtime stack version 2. If FUNCTIONS_WORKER_RUNTIME is set to "dotnet", check the value of "netFrameworkVersion". If set to "powershell", check "powerShellVersion". Same for other programming languages. 3. Refer to below table, if for function v4, "netFrameworkVersion" is "v4.0" or "powerShellVersion" is "~6", those language stack versions are unsupported in V4, you'll then see the warning message on portal and runtime got set to "custom" automatically. Language 1.x 2.x 3.x 4.x C# GA (.NET Framework 4.8) GA (.NET Core 2.11) GA (.NET Core 3.1) GA (.NET 5.0) GA (.NET 6.0) JavaScript GA (Node.js 6) GA (Node.js 10 & 😎 GA (Node.js 14, 12, & 10) GA (Node.js 14) GA (Node.js 16) F# GA (.NET Framework 4.8) GA (.NET Core 2.11) GA (.NET Core 3.1) GA (.NET 6.0) Java N/A GA (Java 😎 GA (Java 11 & 😎 GA (Java 11 & 😎 PowerShell N/A GA (PowerShell Core 6) GA (PowerShell 7.0 & Core 6) GA (PowerShell 7.0) Python N/A GA (Python 3.7 & 3.6) GA (Python 3.9, 3.8, 3.7, & 3.6) GA (Python 3.9, 3.8, 3.7) TypeScript2 N/A GA GA GA Soft reminder: For .NET function app, function runtime [~2] your app will be automatically upgraded to run on .NET Core 3.1, which is a long-term support version of .NET Core 3. (Even if it mention .NET Core is only supported for 3.x. [~2.0] You could choose to pin to "~2.0" to stay with .NET Core 2.2. Ref Cause: Your V3 function app's netFrameWorkVersion has been on .NET 4.0. Function V4 runtime requires .NET 6.0. The platform didn’t update it automatically, this is to avoid breaking customer’s applications who uses any method/type unsupported in .NET 6.0. We'll leave this .NET version upgrade action(updating "netFrameworkVersion") to customers, and with the warning message to remind that the function v4 will need .NET 6.0. You could then decide if the function is ready to be upgraded to v4 from older runtime version. Resolution: For dotnet app ====================================== Use Azure CLI cmds to update "netFrameworkVersion" in app config for app or app slots: az functionapp config set --net-framework-version v6.0 -n <APP_NAME> -g <RESOURCE_GROUP_NAME> az functionapp config set --net-framework-version v6.0 -n <APP_NAME> -g <RESOURCE_GROUP_NAME> --slot <SLOT_NAME> Or use resource explorer resources.azure.com -> find web app -> config -> web -> netFrameworkVersion update to V6.0. For other languages ====================================== You could update the language version on portal too Also please make sure your local project is compatible with your selected language version. Reference: Actions needed for upgrading to V4 https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions?tabs=in-process%2Cv4&pivots=programming-language-csharp#azure [Issue 2] Function App returns 503 Server unavailable After upgrading your function App to "~4", the function app started to give 503 errors. Troubleshooting: 503 server error for function app may indicate a host related issue such as "host failed to start up". If your function app enables app insight, you could run below query to get more error details: traces | where severityLevel >= 2 In some cases, we find the error which caused host to fail as below: Cause: Function V4 required a minimum version for supported extensions. The functions host will enforce the proposed minimum versions in the table below. If an older version of one of the following extensions is present, the host will throw an error specifying the minimum required version and fail to start. Resolution: For dotnet app ====================================== Please do a set of NuGet updates to get the supported extensions installed for affected extensions. For other languages ====================================== Please upgrade to extension bundle version 2.x or later Reference: Function V4 required a minimum version for supported extensions: https://github.com/Azure/Azure-Functions/issues/1987 [Issue 3] Function v4 fallback to V2 Your function app is built with V4 runtime locally, but when you try to deploy it via Cloud Shell, you observe below warning. The deployment completed but app responded 502/503. Your app's still using runtime V2 rather than V4. "You're trying to publish to a non-v2 function app from v2 tooling. You can pass --force to force update the app to v2, or switch to v1 or v3 tooling for publishing" Cause: The publish tooling Azure Function Core tools version needs to be aligned with function app's runtime version. Develop app v3 -> 3.x Core Tools Develop app v4 -> 4.x Core Tools There're other changes needed for VS Code. Resolution: 1. Upgrade function app runtime version via Azure CLI or portal app setting change: az functionapp config appsettings set --name <FUNCTION_APP> \ --resource-group <RESOURCE_GROUP> \ --settings FUNCTIONS_EXTENSION_VERSION=<VERSION> 2. Upgrade function core tool to version 4.x. npm i -g azure-functions-core-tools@4 --unsafe-perm true Reference: View and update current runtime version: https://docs.microsoft.com/en-us/azure/azure-functions/set-runtime-version?tabs=azurecli#view-and-update-the-current-runtime-version [Issue 4] Function v4 host failed to start up due to host ID collision Your function app is upgraded to V4 runtime, you migrated function app to use corresponding language version and updated with the latest SDK such as Azure.Messasing.ServiceBus library too. But the app has below issues: 500/503 Service is unavailable You observed error in App insight logs/diagnose and solve problem -> Function App down or reporting errors "A collision for Host ID 'xxxx' was detected in the configured storage account. For more information, see https://aka.ms/functions-hostid-collision." Cause: Your function app name has more than 32 characters and it's using a storage account shared with other function apps. Starting with version 3.x of the Functions runtime, host ID collision is detected and a warning is logged. In version 4.x, an error is logged and the host is stopped, resulting in a hard failure to prevent the host from starting. Ref for more details. The Functions Host uses a Host ID to uniquely identify a particular Function App. By default, the ID is auto-generated from the Function App name, by taking the first 32 characters. This ID is then used when storing per-app correlation and tracking information in the linked storage account. When you have function apps with names longer than 32 characters and when the first 32 characters are identical, this truncation can result in duplicate host ID values. When two function apps with identical host IDs use the same storage account, you may get a host ID collision because stored data can't be uniquely linked to the correct function app. To prevent this kind of issue, in version 4.x, host ID collision is detected an error is logged, and the host is shut down (hard failure). Resolution: You may choose one of below options: Point your app at a different storage account. [Best practice] Rename your app to something less than 32 characters in length. This will change the computed Host ID for the app and remove the collision. [Most recommended] Provide an explicit Host ID for your app(s) so they don't conflict anymore, via app setting AzureFunctionsWebHost__hostId. In the case of v4 hard failure, you can disable this error via the FUNCTIONS_HOSTID_CHECK_LEVEL app setting. Only do this if none of the options above are possible for you. Possible values for this setting are "Warning" and "Error". [Last choice to bypass the warning] Note: For the 3rd option to customize hostID using app setting AzureFunctionsWebHost__hostId, you might seeing warning in Azure portal or logs saying that it is not recommended to overwrite it, such as "Host id explicitly set in configuration. This is not a recommended configuration and may lead to unexpected behavior." No worries for the warning. If the you’ve done this in accordance with this guidance, the app will be fine. This is one of the workaround options. PG has emitted this warning when the host ID is explicitly set because it’s not the default configuration. For example, if application slots are used, you need to set different hostID values for those slots. If the condition allows, the most recommended resolution will be to shorten the app names, but not required. Reference: Public wiki regarding host collision: https://github.com/Azure/azure-functions-host/wiki/Host-IDs#host-id-collisions App setting AzureFunctionsWebHost__hostId: https://docs.microsoft.com/en-us/azure/azure-functions/functions-app-settings#azurefunctionswebhost__hostid Function host reminder public documentation: https://docs.microsoft.com/en-us/azure/azure-functions/storage-considerations#host-id-considerations Github discussion regarding host collision: https://github.com/Azure/azure-functions-host/issues/2015 Most of above actions are mentioned in doc such as Update app setting Update .net framework version Update nuget package reference version Update Azure Core Tools Version … Nowadays, migration across different runtime version is safer and more convenient, and doesn't require significant code change. Just need a little bit more attention to the related tools/packages upgrade, then all will be good! Feel free to comment below if you've any other questions!
