Felsöka en app i Azure App Service med Visual Studio

Översikt

Den här självstudien visar hur du använder Visual Studio-verktyg för att felsöka en app i App Service, genom att köra i felsökningsläge via fjärrläge eller genom att visa programloggar och webbserverloggar.

Du får lära dig detta:

• Vilka apphanteringsfunktioner som är tillgängliga i Visual Studio.
• Hur du använder Visual Studio fjärrvy för att göra snabba ändringar i en fjärrapp.
• Hur du fjärrkörningar i felsökningsläget när ett projekt körs i Azure, både för en app och för ett webbjobb.
• Hur du skapar programspårningsloggar och visar dem när programmet skapar dem.
• Så här visar du webbserverloggar, inklusive detaljerade felmeddelanden och spårning av misslyckade förfrågningar.
• Hur du skickar diagnostikloggar till ett Azure Storage konto och visar dem där.

Om du har Visual Studio Ultimate kan du också använda IntelliTrace för felsökning. IntelliTrace omfattas inte i den här självstudien.

Förutsättningar

Den här självstudien fungerar med utvecklingsmiljön, webbprojektet och App Service som du konfigurerade i Skapa en ASP.NET-app i Azure App Service. I avsnitten webjobs behöver du det program som du skapar i Kom igång med Azure WebJobs SDK.

De kodexempel som visas i den här självstudien är för en C# MVC-webbapp, men felsökningsprocedurerna är desamma för Visual Basic och Web Forms program.

Självstudien förutsätter att du använder Visual Studio 2019.

Funktionen för strömningsloggar fungerar bara för program som är .NET Framework 4 eller senare.

Appkonfiguration och -hantering

Visual Studio ger åtkomst till en delmängd av apphanteringsfunktionerna och konfigurationsinställningarna som är tillgängliga i Azure Portal. I det här avsnittet ser du vad som är tillgängligt med hjälp av Server Explorer. Om du vill se de senaste integreringsfunktionerna i Azure kan du även prova Cloud Explorer. Du kan öppna båda fönstren från menyn Visa.

1. Om du inte redan är inloggad på Azure i Visual Studio högerklickar du på Azure och väljer Anslut för Microsoft Azure prenumeration i Server Explorer.

   Ett alternativ är att installera ett hanteringscertifikat som ger åtkomst till ditt konto. Om du väljer att installera ett certifikat högerklickar du på Azure-noden i Server Explorer och väljer sedan Hantera och filtrera prenumerationer på snabbmenyn. I dialogrutan Hantera Microsoft Azure prenumerationer klickar du på fliken Certifikat och sedan på Importera. Följ anvisningarna för att ladda ned och importera sedan en prenumerationsfil (kallas även en .publishsettings-fil) för ditt Azure-konto.

   Anteckning

   Om du laddar ned en prenumerationsfil sparar du den i en mapp utanför källkodskatalogerna (till exempel i mappen Hämtade filer) och tar sedan bort den när importen har slutförts. En obehörig användare som får åtkomst till prenumerationsfilen kan redigera, skapa och ta bort dina Azure-tjänster.

   Mer information om hur du ansluter till Azure-resurser från Visual Studio finns i Tilldela Azure-roller med hjälp av Azure Portal.

2. I Server Explorer expanderar du Azure och App Service.

3. Expandera den resursgrupp som innehåller den app som du skapade i Skapa en ASP.NET-app i Azure App Service.Högerklicka sedan på appnoden och klicka på Visa Inställningar.

   

   Fliken Azure-webbapp visas och du kan se de apphanterings- och konfigurationsuppgifter som är tillgängliga i Visual Studio.

   

   I den här självstudien använder du listrutan för loggning och spårning. Du kommer också att använda fjärrfelsökning, men du kommer att använda en annan metod för att aktivera den.

   Information om rutorna App-Inställningar och Anslutningssträngar i det här fönstret finns i Azure App Service: How Application Strings and Connection Strings Work.

   Om du vill utföra en apphanteringsaktivitet som inte kan utföras i det här fönstret klickar du på Öppna i Hanteringsportal för att öppna ett webbläsarfönster till Azure Portal.

Få åtkomst till appfiler i Server Explorer

Du distribuerar vanligtvis ett webbprojekt med flaggan i Web.config fil inställd på eller , vilket innebär att du inte får något customErrors On RemoteOnly användbart felmeddelande när något går fel. För många fel är allt du får en sida som något av följande:

Serverfel i "/"-program:

Ett fel inträffade:

Webbplatsen kan inte visa sidan

Ofta är det enklaste sättet att hitta orsaken till felet att aktivera detaljerade felmeddelanden, vilket förklaras i den första av föregående skärmbilder. Detta kräver en ändring i den distribuerade Web.config filen. Du kan redigera Web.config Web.config-filen i projektet och distribuera om projektet eller skapa en transformering och distribuera en felsökningsbygge, men det går snabbare: i Solution Explorer kan du visa och redigera filer direkt i fjärrappen med fjärrvyfunktionen.

1. I Server Explorer expanderar du Azure, App Service, expanderar den resursgrupp som din app finns i och expanderar sedan noden för din app.

   Du ser noder som ger dig åtkomst till appens innehållsfiler och loggfiler.

2. Expandera noden Filer och dubbelklicka på Web.config fil.

   

   Visual Studio öppnar Web.config från fjärrappen och visar [Remote] bredvid filnamnet i namnlisten.

3. Lägg till följande rad i system.web elementet :

   <customErrors mode="Off"></customErrors>

   

4. Uppdatera webbläsaren som visar det ohjälpliga felmeddelandet. Nu visas ett detaljerat felmeddelande, till exempel i följande exempel:

   

   (Felet som visas skapades genom att lägga till raden som visas i rött i Views\Home\Index.cshtml.)

Att redigera Web.config är bara ett exempel på scenarier där möjligheten att läsa och redigera filer i din App Service gör felsökning enklare.

Fjärrfelsökning av appar

Om det detaljerade felmeddelandet inte innehåller tillräckligt med information och du inte kan skapa felet igen lokalt, är ett annat sätt att felsöka att köra i felsökningsläge via fjärrstyrning. Du kan ange brytpunkter, ändra minnet direkt, stega igenom koden och även ändra kodsökvägen.

Fjärrfelsökning fungerar inte i Express-versioner av Visual Studio.

Det här avsnittet visar hur du fjärrsöker med hjälp av det projekt som du skapar i Skapa en ASP.NET-app i Azure App Service.

1. Öppna webbprojektet som du skapade i Skapa en ASP.NET i Azure App Service.

2. Öppna Controllers\HomeController.cs.

3. Ta bort About() metoden och infoga följande kod i dess ställe.

   public ActionResult About()
   {
       string currentTime = DateTime.Now.ToLongTimeString();
       ViewBag.Message = "The current time is " + currentTime;
       return View();
   }
   

4. Ange en brytpunkt på ViewBag.Message raden.

5. I Solution Explorer högerklickar du på projektet och klickar på Publicera.

6. I listrutan Profil väljer du samma profil som du använde i Skapa en ASP.NET i Azure App Service. Klicka sedan på Inställningar.

7. I dialogrutan Publicera klickar du på fliken Inställningar och ändrar sedan Konfiguration till Felsök och klickar sedan på Spara.

   

8. Klicka på Publicera. När distributionen är klar och webbläsaren öppnar Azure-URL:en för din app stänger du webbläsaren.

9. I Server Explorer högerklickar du på din app och klickar sedan på Attach Debugger (Bifoga felsökare).

   

   Webbläsaren öppnas automatiskt på startsidan som körs i Azure. Du kan behöva vänta i 20 sekunder medan Azure uppsättningar servern för felsökning. Den här fördröjningen inträffar bara första gången du kör i felsökningsläge på en app under en 48-timmarsperiod. När du startar felsökningen igen under samma period finns det ingen fördröjning.

   Anteckning

   Om du har problem med att starta felsökningsprogrammet kan du försöka göra det med hjälp av Cloud Explorer i stället för Server Explorer.

10. Klicka på Om på menyn.

    Visual Studio stoppas på brytpunkten och koden körs i Azure, inte på den lokala datorn.

11. Hovra över currentTime variabeln för att se tidsvärdet.

    

    Den tid du ser är Tiden för Azure-servern, som kan finnas i en annan tidszon än den lokala datorn.

12. Ange ett nytt värde för currentTime variabeln, till exempel "Körs nu i Azure".

13. Tryck på F5 för att fortsätta köra.

    Sidan Om som körs i Azure visar det nya värdet som du angav i variabeln currentTime.

    

Fjärrfelsökning av webbjobb

Det här avsnittet visar hur du fjärrsöker med hjälp av det projekt och den app som du skapar i Kom igång med Azure WebJobs SDK.

Funktionerna som visas i det här avsnittet är endast tillgängliga i Visual Studio 2013 med uppdatering 4 eller senare.

Fjärrfelsökning fungerar bara med kontinuerliga webbjobb. Schemalagda webbjobb och webbjobb på begäran stöder inte felsökning.

1. Öppna webbprojektet som du skapade i Kom igång med Azure WebJobs SDK.

2. I ContosoAdsWebJob-projektet öppnar du Functions.cs.

3. Ange en brytpunkt för den första instruktionen i GnerateThumbnail metoden .

   

4. I Solution Explorer högerklickar du på webbprojektet (inte webbjobbsprojektet) och klickar på Publicera.

5. I listrutan Profil väljer du samma profil som du använde i Kom igång med Azure WebJobs SDK.

6. Klicka på Inställningar och ändra Konfiguration till Felsök och klicka sedan på Publicera.

   Visual Studio distribuerar webb- och webbjobbsprojekten, och webbläsaren öppnar Azure-URL:en för din app.

7. I Server Explorer expanderar du Azure > App Service > din resursgrupp > din app > WebJobs > Continuous och högerklickar sedan på ContosoAdsWebJob.

8. Klicka på Attach Debugger (Bifoga felsökningsprogrammet).

   

   Webbläsaren öppnas automatiskt på startsidan som körs i Azure. Du kan behöva vänta i 20 sekunder medan Azure uppsättningar servern för felsökning. Den här fördröjningen inträffar bara första gången du kör i felsökningsläge på en app under en 48-timmarsperiod. När du startar felsökningen igen under samma period finns det ingen fördröjning.

9. Skapa en ny annons i webbläsaren som öppnas på contoso Ads-startsidan.

   När du skapar en annons skapas ett kömeddelande som hämtas av webbjobbet och bearbetas. När WebJobs SDK anropar funktionen för att bearbeta kömeddelandet når koden din brytpunkt.

10. När felsökaren bryts vid brytpunkten kan du undersöka och ändra variabelvärden medan programmet kör molnet. I följande bild visar felsökningsprogrammet innehållet i objektet blobInfo som skickades till GenerateThumbnail metoden .

    

11. Tryck på F5 för att fortsätta köra.

    Metoden GenerateThumbnail slutför skapandet av miniatyrbilden.

12. Uppdatera indexsidan i webbläsaren så visas miniatyrbilden.

13. Tryck Visual Studio SKIFT + F5 för att stoppa felsökningen i den här felsökningen.

14. I Server Explorer högerklickar du på noden ContosoAdsWebJob och klickar på Visa instrumentpanel.

15. Logga in med dina Azure-autentiseringsuppgifter och klicka sedan på webbjobbsnamnet för att gå till sidan för ditt webbjobb.

    

    Instrumentpanelen visar att GenerateThumbnail funktionen har körts nyligen.

    (Nästa gång du klickar på Visa instrumentpanel behöver du inte logga in och webbläsaren går direkt till sidan för webbjobbet.)

16. Klicka på funktionsnamnet för att se information om funktionskörningen.

    

Om funktionen skrev loggar kandu klicka på VäxlaUtflöde för att se dem.

Information om fjärrfelsökning

• Du rekommenderas inte att köra i felsökningsläge i produktion. Om din produktionsapp inte skalas ut till flera serverinstanser förhindrar felsökning webbservern från att svara på andra begäranden. Om du har flera webbserverinstanser får du en slumpmässig instans när du ansluter till felsökaren och du kan inte se till att efterföljande webbläsarbegäranden går till samma instans. Dessutom distribuerar du vanligtvis inte en felsökningsbygge till produktion, och kompileringsoptimeringar för versioner kan göra det omöjligt att visa vad som händer rad för rad i källkoden. Vid felsökning av produktionsproblem är den bästa resursen programspårning och webbserverloggar.

• Undvik långa stopp vid brytpunkter vid fjärrfelsökning. Azure behandlar en process som har stoppats i mer än några minuter som en process som inte svarar och stänger av den.

• När du felsöker skickar servern data till en Visual Studio, vilket kan påverka bandbreddsavgifterna. Information om bandbreddshastigheter finns i Priser för Azure.

• Kontrollera att debug attributet för compilation elementet iWeb.confighar angetts till true. Det är inställt på true som standard när du publicerar en felsökningskonfiguration.

  <system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>
  

• Om du upptäcker att felsökaren inte går in i koden som du vill felsöka kan du behöva ändra Just My Code inställningen. Mer information finns i Ange om du endast vill felsöka användarkod med hjälp av Just My Code i Visual Studio.

• En timer startar på servern när du aktiverar fjärrfelsökningsfunktionen och efter 48 timmar stängs funktionen av automatiskt. Den här gränsen på 48 timmar görs av säkerhets- och prestandaskäl. Du kan enkelt aktivera funktionen igen så många gånger du vill. Vi rekommenderar att du lämnar den inaktiverad när du inte aktivt felsöker.

• Du kan koppla felsökningsprogrammet manuellt till valfri process, inte bara appprocessen (w3wp.exe). Mer information om hur du använder felsökningsläget i Visual Studio finns i Felsökning i Visual Studio.

Översikt över diagnostikloggar

Ett ASP.NET som körs i en App Service-app kan skapa följande typer av loggar:

• Programspårningsloggar
  Programmet skapar loggarna genom att anropa metoder för klassen System.Diagnostics.Trace.
• Webbserverloggar
  Webbservern skapar en loggpost för varje HTTP-begäran till appen.
• Detaljerade felmeddelandeloggar
  Webbservern skapar en HTML-sida med ytterligare information för misslyckade HTTP-begäranden (begäranden som resulterar i statuskod 400 eller högre).
• Spårningsloggar för misslyckade förfrågningar
  Webbservern skapar en XML-fil med detaljerad spårningsinformation för misslyckade HTTP-begäranden. Webbservern tillhandahåller också en XSL-fil för att formatera XML-filen i en webbläsare.

Loggning påverkar appens prestanda, så Azure ger dig möjlighet att aktivera eller inaktivera varje typ av logg efter behov. För programloggar kan du ange att endast loggar över en viss allvarlighetsgrad ska skrivas. När du skapar en ny app är all loggning inaktiverad som standard.

Loggar skrivs till filer i en LogFiles-mapp i filsystemet i din app och är tillgängliga via FTP. Webbserverloggar och programloggar kan också skrivas till ett Azure Storage konto. Du kan behålla en större mängd loggar i ett lagringskonto än vad som är möjligt i filsystemet. Du är begränsad till högst 100 megabyte loggar när du använder filsystemet. (Filsystemloggar är endast för kortsiktig kvarhållning. Azure tar bort gamla loggfiler för att göra plats för nya när gränsen har nåtts.)

Skapa och visa spårningsloggar för program

I det här avsnittet utför du följande uppgifter:

• Lägg till spårningsutdrag i webbprojektet som du skapade i Kom igång med Azure och ASP.NET.
• Visa loggarna när du kör projektet lokalt.
• Visa loggarna när de genereras av programmet som körs i Azure.

Information om hur du skapar programloggar i WebJobs finns i How to work with Azure queue storage using the WebJobs SDK - How to write logs. Följande anvisningar för att visa loggar och kontrollera hur de lagras i Azure gäller även för programloggar som skapas av WebJobs.

Lägga till spårningsutdrag i programmet

1. Öppna Controllers\HomeController.cs och ersätt metoderna , och med följande kod för att lägga till -instruktioner Index och en About Contact Trace using -instruktion för System.Diagnostics :

   public ActionResult Index()
   {
       Trace.WriteLine("Entering Index method");
       ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
       Trace.TraceInformation("Displaying the Index page at " + DateTime.Now.ToLongTimeString());
       Trace.WriteLine("Leaving Index method");
       return View();
   }
   
   public ActionResult About()
   {
       Trace.WriteLine("Entering About method");
       ViewBag.Message = "Your app description page.";
       Trace.TraceWarning("Transient error on the About page at " + DateTime.Now.ToShortTimeString());
       Trace.WriteLine("Leaving About method");
       return View();
   }
   
   public ActionResult Contact()
   {
       Trace.WriteLine("Entering Contact method");
       ViewBag.Message = "Your contact page.";
       Trace.TraceError("Fatal error on the Contact page at " + DateTime.Now.ToLongTimeString());
       Trace.WriteLine("Leaving Contact method");
       return View();
   }        
   

2. Lägg till using System.Diagnostics; en -instruktion överst i filen.

Visa spårningsutdata lokalt

1. Tryck på F5 för att köra programmet i felsökningsläge.

   Standardspårningslyssnaren skriver alla spårningsutdata till utdatafönstret, tillsammans med andra felsökningsutdata. Följande bild visar utdata från de spårningsutdrag som du lade till i Index metoden .

   

   Följande steg visar hur du visar spårningsutdata på en webbsida, utan att kompilera i felsökningsläge.

2. Öppna programmet Web.config (den som finns i projektmappen) och lägg till ett -element i slutet av filen <system.diagnostics> precis före det avslutande </configuration> elementet:

   <system.diagnostics>
   <trace>
     <listeners>
       <add name="WebPageTraceListener"
           type="System.Web.WebPageTraceListener,
           System.Web,
           Version=4.0.0.0,
           Culture=neutral,
           PublicKeyToken=b03f5f7f11d50a3a" />
     </listeners>
   </trace>
   </system.diagnostics>
   

låter WebPageTraceListener dig visa spårningsutdata genom att bläddra till /trace.axd .

1. Lägg till ett spårningselement <system.web> under Web.config filen, till exempel följande exempel:

   <trace enabled="true" writeToDiagnosticsTrace="true" mostRecent="true" pageOutput="false" />
   

2. Tryck på CTRL+F5 för att köra programmet.

3. I adressfältet i webbläsarfönstret lägger du till trace.axd i URL:en och trycker sedan på Retur (URL:en liknar http://localhost:53370/trace.axd ).

4. På sidan Programspårning klickar du på Visa information på den första raden (inte raden BrowserLink).

   

   Sidan Information om begäran visas och i avsnittet Spårningsinformation visas utdata från de spårningsutdrag som du lade till i Index metoden .

   

   Som standard trace.axd är endast tillgängligt lokalt. Om du vill göra den tillgänglig från en fjärrapp kan du lägga till i elementet i localOnly="false" trace Web.config-filen, som du ser i följande exempel:

   <trace enabled="true" writeToDiagnosticsTrace="true" localOnly="false" mostRecent="true" pageOutput="false" />
   

   Aktivering i en trace.axd produktionsapp rekommenderas dock inte av säkerhetsskäl. I följande avsnitt visas ett enklare sätt att läsa spårningsloggar i en App Service app.

Visa spårningsutdata i Azure

1. I Solution Explorer högerklickar du på webbprojektet och klickar på Publicera.

2. I dialogrutan Publicera webbplats klickar du på Publicera.

   När Visual Studio publicerar uppdateringen öppnas ett webbläsarfönster på startsidan (förutsatt att du inte rensade mål-URL:en på fliken Anslutning).

3. I Server Explorer högerklickar du på din app och väljer Visa strömningsloggar.

   

   Fönstret Utdata visar att du är ansluten till loggströmningstjänsten och lägger till en meddelanderad varje minut som går utan någon logg att visa.

   

4. I webbläsarfönstret som visar programmets startsida klickar du på Kontakta.

   Inom några sekunder visas utdata från spårningen på felnivå som du lade till Contact i metoden i fönstret Utdata.

   

   Visual Studio visar bara spårningar på felnivå eftersom det är standardinställningen när du aktiverar loggövervakningstjänsten. När du skapar en App Service-app inaktiveras all loggning som standard, som du såg när du öppnade inställningssidan tidigare:

   

   Men när du har valt Visa strömningsloggar Visual Studio automatiskt Application Logging (filsystem) till Fel, vilket innebär att felnivåloggar rapporteras. Om du vill se alla spårningsloggar kan du ändra den här inställningen till Utförlig. När du väljer en allvarlighetsgrad som är lägre än fel rapporteras även alla loggar med högre allvarlighetsgrad. Så när du väljer utförligt visas även informations-, varnings- och felloggar.

5. I Server Explorer högerklickar du på appen och klickar sedan på Visa Inställningar som du gjorde tidigare.

6. Ändra Application Logging (filsystem) till Utförlig och klicka sedan på Spara.

   

7. I webbläsarfönstret som nu visar sidan Kontakt klickar du på Start och sedan på Om och sedan på Kontakt.

   Inom några sekunder visar fönstret Utdata alla spårningsutdata.

   

   I det här avsnittet har du aktiverat och inaktiverat loggning med hjälp av appinställningar. Du kan också aktivera och inaktivera spårningslyssnare genom att ändra Web.config fil. Men om du ändrar Web.config-filen återanvänds inte appdomänen, medan aktivering av loggning via appkonfigurationen inte gör det. Om problemet tar lång tid att återskapa, eller om det är tillfälligt, kan återanvändning av appdomänen "åtgärda" det och tvinga dig att vänta tills det händer igen. Genom att aktivera diagnostik i Azure kan du börja samla in felinformation direkt utan att återanvända appdomänen.

Funktioner i utdatafönstret

Fliken Microsoft Azure loggar i utdatafönstret har flera knappar och en textruta:

Dessa utför följande funktioner:

• Rensa fönstret Utdata.
• Aktivera eller inaktivera radbyte.
• Starta eller stoppa övervakningsloggar.
• Ange vilka loggar som ska övervakas.
• Ladda ned loggar.
• Filtrera loggar baserat på en söksträng eller ett reguljärt uttryck.
• Stäng fönstret Utdata.

Om du anger en söksträng eller ett reguljärt uttryck Visual Studio loggningsinformation på klienten. Det innebär att du kan ange villkoren när loggarna visas i fönstret Utdata och du kan ändra filtreringsvillkor utan att behöva återskapa loggarna.

Visa webbserverloggar

Webbserverloggar registrerar all HTTP-aktivitet för appen. För att kunna se dem i utdatafönstret måste du aktivera dem för appen och Visual Studio att du vill övervaka dem.

1. På fliken Azure Web App Configuration som du öppnade från Server Explorer ändrar du Webbserverloggning till På och klickar sedan på Spara.

   

2. I utdatafönstret klickar du på knappen Ange vilka Microsoft Azure loggar som ska övervakas.

   

3. I dialogrutan Microsoft Azure Loggningsalternativ väljer du Webbserverloggar och klickar sedan på OK.

   

4. I webbläsarfönstret som visar appen klickar du på Start, sedan på Om och sedan på Kontakta.

   Programloggarna visas vanligtvis först, följt av webbserverloggarna. Du kan behöva vänta en stund tills loggarna visas.

   

När du först aktiverar webbserverloggar med hjälp av Visual Studio skriver Azure loggarna till filsystemet som standard. Alternativt kan du använda den här Azure Portal att ange att webbserverloggar ska skrivas till en blobcontainer i ett lagringskonto.

Om du använder portalen för att aktivera webbserverloggning till ett Azure Storage-konto och sedan inaktiverar loggning i Visual Studio när du återaktiverar loggning Visual Studio inställningarna för lagringskontot återställs.

Visa detaljerade felmeddelandeloggar

Detaljerade felloggar innehåller ytterligare information om HTTP-begäranden som resulterar i felsvarskoder (400 eller högre). För att kunna se dem i fönstret Utdata måste du aktivera dem för appen och Visual Studio att du vill övervaka dem.

1. På fliken Azure Web App Configuration som du öppnade från Server Explorer ändrar du Detaljerade felmeddelanden till På och klickar sedan på Spara.

   

2. I utdatafönstret klickar du på knappen Ange vilka Microsoft Azure loggar som ska övervakas.

3. I dialogrutan Microsoft Azure Loggningsalternativ klickar du på Alla loggar och sedan på OK.

   

4. I adressfältet i webbläsarfönstret lägger du till ett extra tecken i URL:en för att orsaka ett 404-fel (till exempel http://localhost:53370/Home/Contactx ), och trycker på Retur.

   Efter några sekunder visas den detaljerade felloggen i fönstret Visual Studio Utdata.

   

   Kontrollera och klicka på länken för att se loggutdata formaterade i en webbläsare:

   

Ladda ned filsystemloggar

Alla loggar som du kan övervaka i fönstret Utdata kan också laddas ned som en .zip fil.

1. I fönstret Utdata klickar du på Ladda ned strömningsloggar.

   

   Utforskaren öppnas i mappen Hämtade filer med den nedladdade filen vald.

   

2. Extrahera .zip så ser du följande mappstruktur:

   

   • Programspårningsloggar finns.txt i mappen LogFiles\Application.

   • Webbserverloggar finns i .log-filer i mappen LogFiles\http\RawLogs. Du kan använda ett verktyg som Log Parser för att visa och ändra dessa filer.

   • Detaljerade felmeddelandeloggar finns i .html i mappen LogFiles\DetailedErrors.

     (Mappen distributioner är för filer som skapats av källkontrollpublicering. Den har inte något relaterat till Visual Studio publicering. Git-mappen är till för spårningar som rör publicering av källkontroll och strömningstjänsten för loggfiler.)

Visa spårningsloggar för misslyckade förfrågningar

Spårningsloggar för misslyckade förfrågningar är användbara när du behöver förstå informationen om hur IIS hanterar en HTTP-begäran, i scenarier som URL-omskrivning eller autentiseringsproblem.

App Service-appar använder samma spårningsfunktioner för misslyckade förfrågningar som har varit tillgängliga med IIS 7.0 och senare. Du har dock inte åtkomst till de IIS-inställningar som konfigurerar vilka fel som loggas. När du aktiverar spårning av misslyckade förfrågningar fångas alla fel.

Du kan aktivera spårning av misslyckade förfrågningar med hjälp Visual Studio, men du kan inte visa dem i Visual Studio. Dessa loggar är XML-filer. Tjänsten för strömningslogg övervakar endast filer som anses vara läsbara i klartextläge: .txt, .html och .log-filer.

Du kan visa spårningsloggar för misslyckade förfrågningar i en webbläsare direkt via FTP eller lokalt när du har använt ett FTP-verktyg för att ladda ned dem till din lokala dator. I det här avsnittet visar du dem direkt i en webbläsare.

1. På fliken Konfiguration i fönstret Azure Web App som du öppnade från Server Explorer ändrar du Spårning av misslyckade förfrågningar till På och klickar sedan på Spara.

   

2. I adressfältet i webbläsarfönstret som visar appen lägger du till ett extra tecken i URL:en och klickar på Retur för att orsaka ett 404-fel.

   Detta gör att en spårningslogg för misslyckade förfrågningar skapas och följande steg visar hur du visar eller laddar ned loggen.

3. I Visual Studio fliken Konfiguration i fönstret Azure Web App klickar du på Öppna i Hanteringsportal.

4. På sidan Azure Portal Inställningar för din app klickar du på Autentiseringsuppgifter för distribution och anger sedan ett nytt användarnamn och lösenord.

   

   Anteckning

   När du loggar in måste du använda det fullständiga användarnamnet med appnamnet med prefixet . Om du till exempel anger "myid" som användarnamn och webbplatsen är "myexample" loggar du in som "myexample\myid".

5. I ett nytt webbläsarfönster går du till den URL som visas under FTP-värdnamn eller FTPS-värdnamn på översiktssidan för din app.

6. Logga in med de FTP-autentiseringsuppgifter som du skapade tidigare (inklusive appnamnsprefixet för användarnamnet).

   Webbläsaren visar appens rotmapp.

7. Öppna mappen LogFiles.

   

8. Öppna mappen med namnet W3SVC plus ett numeriskt värde.

   

   Mappen innehåller XML-filer för alla fel som har loggats efter att du har aktiverat spårning av misslyckade förfrågningar och en XSL-fil som en webbläsare kan använda för att formatera XML-filen.

   

9. Klicka på XML-filen för den misslyckade begäran som du vill visa spårningsinformation för.

   Följande bild visar en del av spårningsinformationen för ett exempelfel.

   

Nästa steg

Du har sett hur Visual Studio gör det enkelt att visa loggar som skapats av en App Service app. Följande avsnitt innehåller länkar till fler resurser om relaterade ämnen:

• App Service felsökning
• Felsökning i Visual Studio
• Fjärrfelsökning i Azure
• Spårning i ASP.NET program
• Analysera webbserverloggar
• Analysera spårningsloggar för misslyckade förfrågningar
• Felsöka Cloud Services

App Service felsökning

Mer information om felsökning av appar i Azure App Service finns i följande resurser:

• Övervaka appar
• Undersöka minnesläckor i Azure App Service med Visual Studio 2013. Microsoft ALM-blogginlägg om Visual Studio funktioner för att analysera problem med hanterat minne.
• Azure App Service onlineverktyg som du bör känna till. Blogginlägg av Amit Apple.

Om du behöver hjälp med en specifik felsökningsfråga startar du en tråd i något av följande forum:

• Azure-forumet på ASP.NET webbplats.
• Azure-forumet på Microsoft Q&A.
• StackOverflow.com.

Felsökning i Visual Studio

Mer information om hur du använder felsökningsläget i Visual Studio finns i Felsöka i Visual Studio och Tips med Visual Studio 2010.

Fjärrfelsökning i Azure

Mer information om fjärrfelsökning för App Service-appar och WebJobs finns i följande resurser:

• Introduktion till fjärrfelsökning Azure App Service.
• Introduktion till fjärrfelsökning Azure App Service del 2 – Fjärrfelsökning inuti
• Introduktion till fjärrfelsökning på Azure App Service del 3 – Multi-Instance-miljö och GIT
• Felsökning av webjobs (video)

Om din app använder ett Azure Web API eller Mobile Services-backend och du behöver felsöka det, se Felsöka .NET-backend i Visual Studio.

Spårning i ASP.NET program

Det finns inga omfattande och uppdaterade introduktioner till ASP.NET spårning på Internet. Det bästa du kan göra är att komma igång med gamla introduktionsmaterial som skrivits för Web Forms eftersom MVC inte fanns ännu, och komplettera det med nyare blogginlägg som fokuserar på specifika problem. Några bra platser att börja på är följande resurser:

• Övervakning och telemetri (skapa Real-World Cloud Apps med Azure).
  E-bokkapitel med rekommendationer för spårning i Azure-molnprogram.

• ASP.NET Spårning
  Gammal men fortfarande en bra resurs för en grundläggande introduktion till ämnet.

• Spårningslyssnare
  Information om spårningslyssnare men inte WebPageTraceListener.

• Genomgång: Integrera ASP.NET spårning med System.Diagnostics-spårning
  Den här artikeln är också gammal, men innehåller ytterligare information som den inledande artikeln inte tar upp.

• Spårning i ASP.NET MVC Razor-vyer
  Förutom spårning i Razor-vyer förklarar inlägget också hur du skapar ett felfilter för att logga alla ohanterade undantag i ett MVC-program. Information om hur du loggar alla ohanterade undantag i ett Web Forms-program finns i Global.asax-exemplet i Fullständigt exempel för Felhanterare på MSDN. Om du i MVC eller Web Forms vill logga vissa undantag men låta standardramverkshanteringen gälla för dem, kan du fånga och återse som i följande exempel:

  try
  {
     // Your code that might cause an exception to be thrown.
  }
  catch (Exception ex)
  {
      Trace.TraceError("Exception: " + ex.ToString());
      throw;
  }
  

• Spårningsloggning för direktuppspelningsdiagnostik från Azure-kommandoraden (plus en skymt!)
  Hur du använder kommandoraden för att göra det som den här självstudien visar hur du gör i Visual Studio. En skymt är ett verktyg för ASP.NET program.

• Använda Web Apps loggning och diagnostik – med David Ebbo och strömmande loggar från Web Apps – med David Ebbo
  Videor av Scott Hanselman och David Ebbo.

För felloggning är ett alternativ till att skriva din egen spårningskod att använda ett loggningsramverk med öppen källkod, till exempel ELMAH. Mer information finns i Scott Hanselman blogginlägg om ELMAH.

Du behöver inte heller använda spårning ASP.NET System.Diagnostics för att hämta strömningsloggar från Azure. Den App Service appströmningsloggtjänsten strömmar alla .txt, .html eller .log-filer som hittas i mappen LogFiles. Därför kan du skapa ett eget loggningssystem som skriver till appens filsystem och filen strömmas och laddas ned automatiskt. Allt du behöver göra är att skriva programkod som skapar filer i mappen d:\home\logfiles.

Analysera webbserverloggar

Mer information om att analysera webbserverloggar finns i följande resurser:

• LogParser
  Ett verktyg för att visa data i webbserverloggar (.log-filer).
• Felsöka IIS-prestandaproblem eller programfel med LogParser
  En introduktion till verktyget Log Parser som du kan använda för att analysera webbserverloggar.
• Blogginlägg av Robert McRay om att använda LogParser
  
• HTTP-statuskoden i IIS 7.0, IIS 7.5 och IIS 8.0

Analysera spårningsloggar för misslyckade förfrågningar

Webbplatsen för Microsoft TechNet innehåller ett avsnitt om spårning av misslyckade förfrågningar, vilket kan vara användbart för att förstå hur du använder dessa loggar. Den här dokumentationen fokuserar dock främst på att konfigurera spårning av misslyckade förfrågningar i IIS, vilket du inte kan göra i Azure App Service.