Dela via

Självstudie: Felsöka en App Service-app med Azure Monitor

  • Artikel

Den här självstudien visar hur du felsöker en App Service-app med Hjälp av Azure Monitor. Exempelappen innehåller kod som är avsedd att uttömma minne och orsaka HTTP 500-fel, så att du kan diagnostisera och åtgärda problemet med Hjälp av Azure Monitor. När du är klar har du en exempelapp som körs på App Service på Linux integrerad med Azure Monitor.

Azure Monitor maximerar tillgängligheten och prestandan för dina program och tjänster genom att leverera en omfattande lösning för att samla in, analysera och agera på telemetri från dina molnmiljöer och lokala miljöer.

I den här självstudien lär du dig att:

  • Konfigurera en webbapp med Azure Monitor
  • Skicka konsolloggar till Log Analytics
  • Använda loggfrågor för att identifiera och felsöka webbappsfel

Du kan följa stegen i den här självstudien i macOS, Linux och Windows.

Om du inte har en Azure-prenumeration skapar du ett kostnadsfritt Azure-konto innan du börjar.

Förutsättningar

För att slutföra självstudierna behöver du:

Skapa Azure-resurser

Först kör du flera kommandon lokalt för att konfigurera en exempelapp som ska användas med den här självstudien. Kommandona skapar Azure-resurser, skapar en distributionsanvändare och distribuerar exempelappen till Azure. Du uppmanas att ange lösenordet som en del av skapandet av distributionsanvändaren.

az group create --name myResourceGroup --location "South Central US"
az webapp deployment user set --user-name <username> --password <password>
az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --sku B1 --is-linux
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app-name> --runtime "PHP|8.1" --deployment-local-git
az webapp config appsettings set --name <app-name> --resource-group myResourceGroup --settings DEPLOYMENT_BRANCH='main'
git clone https://github.com/Azure-Samples/App-Service-Troubleshoot-Azure-Monitor
cd App-Service-Troubleshoot-Azure-Monitor
git branch -m main
git remote add azure <url-from-app-webapp-create>
git push azure main

Konfigurera Azure Monitor

Skapa en Log Analytics-arbetsyta

Nu när du har distribuerat exempelappen till Azure App Service konfigurerar du övervakningsfunktionen för att felsöka appen när problem uppstår. Azure Monitor lagrar loggdata på en Log Analytics-arbetsyta. En arbetsyta är en container som innehåller data och konfigurationsinformation.

I det här steget skapar du en Log Analytics-arbetsyta för att konfigurera Azure Monitor med din app.

az monitor log-analytics workspace create --resource-group myResourceGroup --workspace-name myMonitorWorkspace

Kommentar

För Azure Monitor Log Analytics betalar du för datainmatning och datakvarhållning.

Skapa en diagnostikinställning

Diagnostikinställningar kan användas för att samla in mått för vissa Azure-tjänster i Azure Monitor-loggar för analys med andra övervakningsdata med hjälp av loggfrågor. I den här självstudien aktiverar du webbservern och standardloggarna för utdata/fel. Se loggtyper som stöds för en fullständig lista över loggtyper och beskrivningar.

Du kör följande kommandon för att skapa diagnostikinställningar för AppServiceConsoleLogs (standardutdata/fel) och AppServiceHTTPLogs (webbserverloggar). Ersätt appnamn> och <arbetsytenamn> med dina värden.<

Kommentar

De två första kommandona, resourceID och workspaceID, är variabler som ska användas i kommandot az monitor diagnostic-settings create . Mer information om det här kommandot finns i Skapa diagnostikinställningar med Hjälp av Azure CLI .

resourceID=$(az webapp show -g myResourceGroup -n <app-name> --query id --output tsv)

workspaceID=$(az monitor log-analytics workspace show -g myResourceGroup --workspace-name <workspace-name> --query id --output tsv)

az monitor diagnostic-settings create --resource $resourceID \
 --workspace $workspaceID \
 -n myMonitorLogs \
 --logs '[{"category": "AppServiceConsoleLogs", "enabled": true},
  {"category": "AppServiceHTTPLogs", "enabled": true}]'

Felsöka appen

Bläddra till http://<app-name>.azurewebsites.net.

Exempelappen ImageConverter konverterar inkluderade bilder från JPG till PNG. En bugg har avsiktligt placerats i koden för den här självstudien. Om du väljer tillräckligt många bilder genererar appen ett HTTP 500-fel under bildkonverteringen. Tänk dig att det här scenariot inte övervägdes under utvecklingsfasen. Du använder Azure Monitor för att felsöka felet.

Kontrollera att appen fungerar

Om du vill konvertera bilder klickar du på Tools och väljer Convert to PNG.

Klicka på Verktyg och välj Konvertera till PNG

Välj de två första bilderna och klicka på convert. Detta konverteras.

Välj de två första bilderna

Dela upp appen

Nu när du har verifierat appen genom att konvertera två bilder försöker vi konvertera de första fem bilderna.

Konvertera de första fem bilderna

Den här åtgärden misslyckas och skapar ett HTTP 500 fel som inte testades under utvecklingen.

Konverteringen resulterar i ett HTTP 500-fel

Använda loggfråga för att visa Azure Monitor-loggar

Nu ska vi se vilka loggar som är tillgängliga på Log Analytics-arbetsytan.

Klicka på den här log analytics-arbetsytan för att få åtkomst till din arbetsyta i Azure Portal.

I Azure Portal väljer du din Log Analytics-arbetsyta.

Loggfrågor

Loggfrågor hjälper dig att fullt ut tillämpa värdet för de data som samlas in i Azure Monitor-loggar. Du använder loggfrågor för att identifiera loggarna i både AppServiceHTTPLogs och AppServiceConsoleLogs. Mer information om loggfrågor finns i loggfrågeöversikten .

Visa AppServiceHTTPLogs med loggfråga

Nu när vi har använt appen ska vi visa data som är associerade med HTTP-begäranden som finns i AppServiceHTTPLogs.

  1. Klicka Logs i det vänstra navigeringsfältet.

Logga Anlytics Worksace-loggar

  1. Sök appservice efter och dubbelklicka på AppServiceHTTPLogs.

Log Analytics-arbetsytetabeller

  1. Klicka på Run.

Log Analytics-arbetsyteapptjänstens HTTP-loggar

Frågan AppServiceHTTPLogs returnerar alla begäranden under de senaste 24 timmarna. Kolumnen ScStatus innehåller HTTP-status. Om du vill diagnostisera felen HTTP 500 ScStatus begränsar du till 500 och kör frågan enligt nedan:

AppServiceHTTPLogs
| where ScStatus == 500

Visa AppServiceConsoleLogs med loggfråga

Nu när du har bekräftat HTTP 500s ska vi ta en titt på standardutdata/-fel från appen. Dessa loggar finns i "AppServiceConsoleLogs".

(1) Klicka + för att skapa en ny fråga.

(2) Dubbelklicka på AppServiceConsoleLogs tabellen och klicka på Run.

Eftersom konvertering av fem bilder resulterar i serverfel kan du se om appen också skriver fel genom att ResultDescription filtrera efter fel, som du ser nedan:

AppServiceConsoleLogs |
where ResultDescription  contains "error"

ResultDescription I kolumnen visas följande fel:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted 
(tried to allocate 16384 bytes) in /home/site/wwwroot/process.php on line 20, 
referer: http://<app-name>.azurewebsites.net/

Gå med i AppServiceHTTPLogs och AppServiceConsoleLogs

Nu när du har identifierat både HTTP 500s- och standardfel måste du bekräfta om det finns en korrelation mellan dessa meddelanden. Därefter sammanfogar du tabellerna baserat på tidsstämpeln , TimeGenerated.

Kommentar

En fråga har förberetts för dig som gör följande:

  • Filtrerar HTTPLogs för 500-fel
  • Frågekonsolloggar
  • Ansluter tabellerna på TimeGenerated

Kör följande fråga:

let myHttp = AppServiceHTTPLogs | where  ScStatus == 500 | project TimeGen=substring(TimeGenerated, 0, 19), CsUriStem, ScStatus;  

let myConsole = AppServiceConsoleLogs | project TimeGen=substring(TimeGenerated, 0, 19), ResultDescription;

myHttp | join myConsole on TimeGen | project TimeGen, CsUriStem, ScStatus, ResultDescription;

ResultDescription I kolumnen visas följande fel samtidigt som webbserverfel:

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted 
(tried to allocate 16384 bytes) in /home/site/wwwroot/process.php on line 20, 
referer: http://<app-name>.azurewebsites.net/

Meddelandet anger att minnet har förbrukats på rad 20 i process.php. Nu har du bekräftat att programmet skapade ett fel under HTTP 500-felet. Nu ska vi ta en titt på koden för att identifiera problemet.

Identifiera felet

Öppna och titta på rad 20 i den lokala katalogen process.php .

imagepng($imgArray[$x], $filename);

Det första argumentet, $imgArray[$x], är en variabel som innehåller alla JPG:er (minnesintern) som behöver konvertering. imagepng Dock behöver bara bilden konverteras och inte alla bilder. Förinläsning av bilder är inte nödvändigt och kan orsaka minnesöverbelastning, vilket leder till HTTP 500s. Nu ska vi uppdatera koden för att läsa in bilder på begäran för att se om den löser problemet. Därefter förbättrar du koden för att åtgärda minnesproblemet.

Åtgärda appen

Uppdatera lokalt och distribuera om koden

Du gör följande ändringar för att process.php hantera minnesöverbelastningen:

<?php

//Retrieve query parameters
$maxImages = $_GET['images'];
$imgNames  = explode(",",$_GET['imgNames']);

//Load JPEGs into an array (in memory)
for ($x=0; $x<$maxImages; $x++){
    $filename = './images/converted_' . substr($imgNames[$x],0,-4) . '.png';
    imagepng(imagecreatefromjpeg("./images/" . $imgNames[$x]), $filename);
}

Spara ändringarna på Git och skicka sedan kodändringarna till Azure.

git commit -am "Load images on-demand in process.php"
git push azure main

Bläddra till Azure-appen

Bläddra till http://<app-name>.azurewebsites.net.

Konvertering av bilder bör inte längre generera HTTP 500-fel.

PHP-app som körs i Azure App Service

Rensa resurser

I de föregående stegen skapade du Azure-resurser i en resursgrupp. Om du inte tror att du behöver dessa resurser i framtiden tar du bort resursgruppen genom att köra följande kommando i Cloud Shell:

az group delete --name myResourceGroup

Det kan några minuter att köra kommandot.

Ta bort diagnostikinställningen med följande kommando:

az monitor diagnostic-settings delete --resource $resourceID -n myMonitorLogs

Vad du lärt dig:

  • Konfigurerat en webbapp med Azure Monitor
  • Skickade loggar till Log Analytics
  • Använda loggfrågor för att identifiera och felsöka webbappsfel

Nästa steg