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

Artikel
01/10/2024

Kommentar

Den här artikeln är för Visual Studio 2019. Felsökning i Visual Studio 2022 finns i Fjärrfelsöka ASP.NET Core i Azure App Service.

Ö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 fjärrköra i felsökningsläge eller genom att visa programloggar och webbserverloggar.

Du får lära dig detta:

Vilka apphanteringsfunktioner som är tillgängliga i Visual Studio.
Så här använder du Visual Studio-fjärrvyn för att göra snabba ändringar i en fjärrapp.
Så här kör du felsökningsläget via fjärranslutning när ett projekt körs i Azure, både för en app och för ett webbjobb.
Så här skapar du spårningsloggar för program och visar dem medan programmet skapar dem.
Så här visar du webbserverloggar, inklusive detaljerade felmeddelanden och misslyckad spårning av begäranden.
Så här skickar du 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 beskrivs inte i den här självstudien.

Förutsättningar

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

Kodexemplen som visas i den här självstudien är för ett C# MVC-webbprogram, 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 direktuppspelningsloggar fungerar bara för program som är avsedda fö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 Azure-integreringsfunktionerna kan du även prova Cloud Explorer . Du kan öppna båda fönstren från menyn Visa .

Om du inte redan är inloggad i Azure i Visual Studio högerklickar du på Azure och väljer Anslut till 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 klickar 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.

Kommentar

Om du laddar ned en prenumerationsfil sparar du den i en mapp utanför dina källkodskataloger (till exempel i mappen Nedladdningar) 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.
I Server Explorer expanderar du Azure och expanderar App Service.
Expandera resursgruppen som innehåller den app som du skapade i Skapa en ASP.NET-app i Azure App Service och högerklicka sedan på appnoden och klicka på Visa inställningar.

Fliken Azure Web App visas och du kan se de programhanterings- och konfigurationsuppgifter som är tillgängliga i Visual Studio.

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

Information om rutorna Appinställningar och Anslutningssträngar i det här fönstret finns i Azure App Service: Hur programsträngar och anslutningssträngar fungerar.

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

Komma åt appfiler i Server Explorer

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

Serverfel i "/"-programmet:

Skärmbild som visar ett serverfel i programfelet

Ett fel uppstod:

Skärmbild som visar ett exempel på ett allmänt fel som inträffar i en webbläsare.

Det går inte att visa sidan på webbplatsen

Skärmbild som visar ett meddelande som läser **Webbplatsen kan inte visa sidfelet i en webbläsare**.

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

I Server Explorer expanderar du Azure, expanderar App Service, expanderar resursgruppen 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.
Expandera noden Filer och dubbelklicka på filen Web.config.

Visual Studio öppnar filen Web.config från fjärrappen och visar [Remote] bredvid filnamnet i namnlisten.
Lägg till följande rad i elementet system.web :

<customErrors mode="Off"></customErrors>
Uppdatera webbläsaren som visar det ohjälpsamma felmeddelandet och nu får du ett detaljerat felmeddelande, till exempel följande exempel:

(Felet som visades skapades genom att den rad som visas i rött läggs till iViews\Home\Index.cshtml.)

Att redigera filen Web.config är bara ett exempel på scenarier där det blir enklare att läsa och redigera filer i App Service-appen.

Fjärrfelsökningsappar

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

Fjärrfelsökning fungerar inte i Express-utgåvor av Visual Studio.

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

Öppna webbprojektet som du skapade i Skapa en ASP.NET-app i Azure App Service.
Öppna Controllers\HomeController.cs.

About() Ta bort 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();
}

Ange en brytpunkt på ViewBag.Message raden.
Högerklicka på projektet i Solution Explorer och klicka på Publicera.
I listrutan Profil väljer du samma profil som du använde i Skapa en ASP.NET-app i Azure App Service. Klicka sedan på Inställningar.
I dialogrutan Publicera klickar du på fliken Inställningar och ändrar sedan Konfiguration till Felsök och klickar sedan på Spara.
Klicka på Publicera. När distributionen är klar och webbläsaren öppnas till appens Azure-URL stänger du webbläsaren.
Högerklicka på din app i Server Explorer och klicka sedan på Bifoga felsökningsprogram.

Webbläsaren öppnas automatiskt på startsidan som körs i Azure. Du kan behöva vänta i 20 sekunder eller så medan Azure konfigurerar 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 i en app under en 48-timmarsperiod. När du börjar felsöka igen under samma period finns det ingen fördröjning.

Kommentar

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.
Klicka på Om i menyn.

Visual Studio stoppas på brytpunkten och koden körs i Azure, inte på den lokala datorn.
Hovra över variabeln currentTime för att se tidsvärdet.

Tiden du ser är Azure-servertiden, som kan finnas i en annan tidszon än den lokala datorn.
Ange ett nytt värde för variabeln currentTime , till exempel "Körs nu i Azure".
Tryck på F5 för att fortsätta köra.

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

Fjärrfelsökning av WebJobs

Det här avsnittet visar hur du fjärrfelsöker med hjälp av projektet och appen 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.

Öppna webbprojektet som du skapade i Kom igång med Azure WebJobs SDK.
Öppna Functions.cs i ContosoAdsWebJob-projektet.
Ange en brytpunkt för den första instruktionen GenerateThumbnail i metoden.
Högerklicka på webbprojektet (inte webbjobbsprojektet) i Solution Explorer och klicka på Publicera.
I listrutan Profil väljer du samma profil som du använde i Kom igång med Azure WebJobs SDK.
Klicka på fliken Inställningar och ändra Konfiguration till Felsök och klicka sedan på Publicera.

Visual Studio distribuerar webb- och webbjobbsprojekten och webbläsaren öppnas till Appens Azure-URL.
I Server Explorer expanderar du Azure > App Service > din resursgrupp > din app > WebJobs > Continuous och högerklickar sedan på ContosoAdsWebJob.
Klicka på Bifoga felsökningsprogram.

Webbläsaren öppnas automatiskt på startsidan som körs i Azure. Du kan behöva vänta i 20 sekunder eller så medan Azure konfigurerar 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 i en app under en 48-timmarsperiod. När du börjar felsöka igen under samma period finns det ingen fördröjning.
Skapa en ny annons i webbläsaren som öppnas på startsidan för Contoso Ads.

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 träffar koden brytpunkten.
När felsökningsprogrammet 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 blobInfo-objektet som skickades till GenerateThumbnail metoden.
Tryck på F5 för att fortsätta köra.

Metoden GenerateThumbnail slutför skapandet av miniatyrbilden.
I webbläsaren uppdaterar du sidan Index så ser du miniatyrbilden.
I Visual Studio trycker du på SKIFT+F5 för att sluta felsöka.
Högerklicka på noden ContosoAdsWebJob i Server Explorer och klicka på Visa instrumentpanel.
Logga in med dina Azure-autentiseringsuppgifter och klicka sedan på webbjobbets namn 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, du behöver inte logga in och webbläsaren går direkt till sidan för ditt webbjobb.)
Klicka på funktionsnamnet för att se information om funktionskörningen.

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

Information om fjärrfelsökning

Det rekommenderas inte att köra i felsökningsläge i produktion. Om din produktionsapp inte skalas ut till flera serverinstanser hindrar 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ökningsprogrammet och du kan inte se till att efterföljande webbläsarbegäranden går till samma instans. Dessutom distribuerar du vanligtvis inte en felsökningsversion till produktion, och kompilatoroptimeringar för versionsversioner kan göra det omöjligt att visa vad som händer rad för rad i källkoden. För 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 längre än några minuter som en process som inte svarar och stänger av den.
När du felsöker skickar servern data till Visual Studio, vilket kan påverka bandbreddsavgifterna. Information om bandbreddshastigheter finns i Priser för Azure.
Kontrollera att debug attributet för elementet compilation i filen Web.config är inställt på true. Den är inställd på true som standard när du publicerar en konfiguration för felsökningsversion.
```
<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 inställningen Just My Code. Mer information finns i Ange om endast användarkod ska felsökas med Just My Code i Visual Studio.
En timer startar på servern när du aktiverar fjärrfelsökningsfunktionen och efter 48 timmar inaktiveras funktionen 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 till valfri process manuellt, inte bara appprocessen (w3wp.exe). Mer information om hur du använder felsökningsläge i Visual Studio finns i Felsökning i Visual Studio.

Översikt över diagnostikloggar

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

Programspårningsloggar
Programmet skapar dessa loggar 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 senare).
Spårningsloggar för misslyckade begäranden
Webbservern skapar en XML-fil med detaljerad spårningsinformation för misslyckade HTTP-begäranden. Webbservern innehåller också en XSL-fil för att formatera XML 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 inaktiveras som standard all loggning.

Loggar skrivs till filer i en LogFiles-mapp i appens filsystem 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 mb 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årningsuttryck 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 Så här arbetar du med Azure-kölagring med hjälp av WebJobs SDK – Så här skriver du loggar. Följande instruktioner för att visa loggar och styra hur de lagras i Azure gäller även för programloggar som skapats av WebJobs.

Lägga till spårningsuttryck i programmet

Öppna Controllers\HomeController.cs och ersätt Indexmetoderna , Aboutoch Contact med följande kod för att lägga Trace till instruktioner och en 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();
}

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

Visa spårningsutdata lokalt

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 spårningssatserna 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.

Öppna filen application Web.config (den som finns i projektmappen) och lägg till ett <system.diagnostics> element i slutet av filen 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>

Med WebPageTraceListener kan du visa spårningsutdata genom att bläddra till /trace.axd.

Lägg till ett spårningselement under <system.web> i filen Web.config, till exempel följande exempel:
```
<trace enabled="true" writeToDiagnosticsTrace="true" mostRecent="true" pageOutput="false" />
```
Tryck på CTRL+F5 för att köra programmet.
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).
På sidan Programspårning klickar du på Visa information på den första raden (inte på raden BrowserLink).

Sidan Förfrågningsinformation visas och i avsnittet Spårningsinformation ser du utdata från spårningssatserna 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 localOnly="false" elementet trace i filen Web.config , som du ser i följande exempel:
```
<trace enabled="true" writeToDiagnosticsTrace="true" localOnly="false" mostRecent="true" pageOutput="false" />
```
Aktivering trace.axd i en produktionsapp rekommenderas dock inte av säkerhetsskäl. I följande avsnitt ser du ett enklare sätt att läsa spårningsloggar i en App Service-app.

Visa spårningsutdata i Azure

Högerklicka på webbprojektet i Solution Explorer och klicka på Publicera.
I dialogrutan Publicera webb klickar du på Publicera.

När Visual Studio har publicerat uppdateringen öppnas ett webbläsarfönster på startsidan (förutsatt att du inte rensade mål-URL:en på fliken Anslutning ).
Högerklicka på din app i Server Explorer och välj Visa direktuppspelningsloggar.

Fönstret Utdata visar att du är ansluten till loggströmningstjänsten och lägger till en meddelanderad varje minut som går utan att en logg visas.
I webbläsarfönstret som visar startsidan för programmet klickar du på Kontakt.

Inom några sekunder visas utdata från felnivåspårningen som du lade till i Contact 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 ny App Service-app inaktiveras all loggning som standard, som du såg när du öppnade inställningssidan tidigare:

Men när du valde Visa strömmande loggar ändrade Visual Studio automatiskt Programloggning (filsystem) till Fel, vilket innebär att loggar på felnivå 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 allvarlighetsnivå som är lägre än fel rapporteras även alla loggar för högre allvarlighetsgrad. När du väljer utförligt visas även informations-, varnings- och felloggar.
Högerklicka på appen i Server Explorer och klicka sedan på Visa inställningar som du gjorde tidigare.
Ändra Programloggning (filsystem) till Utförlig och klicka sedan på Spara.
I webbläsarfönstret som nu visar sidan Kontakt klickar du på Start, klickar sedan på Om och sedan på Kontakt.

Inom några sekunder visar utdatafönstret alla dina 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 filen Web.config. Om du ändrar filen Web.config kan appdomänen dock återanvändas, samtidigt som loggning via appkonfigurationen inte aktiveras. Om problemet tar lång tid att återskapa, eller om det är tillfälligt, kan återvinning av appdomänen "åtgärda" det och tvinga dig att vänta tills det händer igen. När du aktiverar diagnostik i Azure kan du börja samla in felinformation omedelbart utan att återanvända appdomänen.

Utdatafönsterfunktioner

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

Skärmbild som visar knapparna och textrutan på fliken Microsoft Azure-loggar i utdatafönstret.

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 filtrerar Visual Studio loggningsinformation på klienten. Det innebär att du kan ange villkoret när loggarna visas i utdatafönstret och du kan ändra filtreringsvillkoren 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 meddela Visual Studio att du vill övervaka dem.

På fliken Konfiguration av Azure Web App som du öppnade från ServerUtforskaren ändrar du Webbserverloggning till På och klickar sedan på Spara.
I utdatafönstret klickar du på knappen Ange vilka Microsoft Azure-loggar som ska övervakas.
I dialogrutan Loggningsalternativ för Microsoft Azure väljer du Webbserverloggar och klickar sedan på OK.
I webbläsarfönstret som visar appen klickar du på Start, klickar sedan på Om och sedan på Kontakt.

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

När du först aktiverar webbserverloggar med hjälp av Visual Studio skriver Azure som standard loggarna till filsystemet. Alternativt kan du använda Azure Portal för 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-lagringskonto och sedan inaktiverar loggning i Visual Studio när du återaktiverar loggning i Visual Studio återställs inställningarna för lagringskontot.

Visa detaljerade felmeddelandeloggar

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

På fliken Konfiguration av Azure Web App som du öppnade från Server Explorer ändrar du Detaljerade felmeddelanden till På och klickar sedan på Spara.
I utdatafönstret klickar du på knappen Ange vilka Microsoft Azure-loggar som ska övervakas.
I dialogrutan Loggningsalternativ för Microsoft Azure klickar du på Alla loggar och sedan på OK.
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 flera sekunder visas den detaljerade felloggen i fönstret Visual Studio-utdata.

Control+ klicka på länken för att se loggutdata formaterad i en webbläsare:

Ladda ned filsystemloggar

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

I fönstret Utdata klickar du på Ladda ned direktuppspelningsloggar.

Utforskaren öppnas Laddar ned mappen med den nedladdade filen markerad.
Extrahera .zip-filen så ser du följande mappstruktur:
- Programspårningsloggar finns i .txt filer 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 filer i mappen LogFiles\DetailedErrors.
  
  (Distributionsmappen är avsedd för filer som skapats av källkontrollpublicering. Den har inget relaterat till Visual Studio-publicering. Git-mappen är avsedd för spårningar relaterade till källkontrollpublicering och loggfilens strömningstjänst.)

Visa spårningsloggar för misslyckade begäranden

Spårningsloggar för misslyckade begäranden ä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 funktioner för spårning av 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 begäranden registreras alla fel.

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

Du kan visa spårningsloggar för misslyckade begäranden i en webbläsare direkt via FTP eller lokalt efter att du har använt ett FTP-verktyg för att ladda ned dem till den lokala datorn. I det här avsnittet visar du dem direkt i en webbläsare.

På fliken Konfiguration i fönstret Azure Web App som du öppnade från Server Explorer ändrar du Spårning av misslyckade begäranden till På och klickar sedan på Spara.
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 begäranden skapas och följande steg visar hur du visar eller laddar ned loggen.
I Visual Studio går du till fliken Konfiguration i fönstret Azure Web App och klickar på Öppna i hanteringsportalen.
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.

Kommentar

När du loggar in måste du använda det fullständiga användarnamnet med appnamnet prefixet för det. Om du till exempel anger "myid" som användarnamn och webbplatsen är "myexample" loggar du in som "myexample\myid".
I ett nytt webbläsarfönster går du till den URL som visas under FTP-värdnamnet eller FTPS-värdnamnet på sidan Översikt för din app.
Logga in med ftp-autentiseringsuppgifterna som du skapade tidigare (inklusive appnamnprefixet för användarnamnet).

Webbläsaren visar appens rotmapp.
Öppna mappen LogFiles.
Öppna mappen med namnet W3SVC plus ett numeriskt värde.

Mappen innehåller XML-filer för eventuella 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.
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:

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

Felsökning av App Service

Mer information om hur du felsöker appar i Azure App Service finns i följande resurser:

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

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

Felsökning i Visual Studio

Mer information om hur du använder felsökningsläge i Visual Studio finns i Felsökning i Visual Studio och Felsökningstips med Visual Studio 2010.

Fjärrfelsökning i Azure

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

Om din app använder ett Azure Web API eller Mobile Services-serverdel och du behöver felsöka det kan du läsa Felsöka .NET-serverdelen i Visual Studio.

Spårning i ASP.NET program

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

Övervakning och telemetri (Skapa verkliga molnappar med Azure).
E-bokskapitlet med rekommendationer för spårning i Azure-molnprogram.
ASP.NET spårning
Gammal men ändå en bra resurs för en grundläggande introduktion till ämnet.
Spåra lyssnare
Information om spårningslyssnare men nämner inte WebPageTraceListener.
Genomgång: Integrera ASP.NET spårning med System.Diagnostics Tracing
Den här artikeln är också gammal, men innehåller ytterligare information som inte beskrivs i introduktionsartikeln.
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 webbformulärprogram finns i exemplet Global.asax i Fullständigt exempel för felhanterare på MSDN. Om du vill logga vissa undantag i MVC eller Webbformulär, men låter standardramverkets hantering börja gälla för dem, kan du fånga och återväxta 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 Glimpse!)
Så här använder du kommandoraden för att göra vad den här självstudien visar hur du gör i Visual Studio. Glimpse är ett verktyg för att felsöka ASP.NET program.
Använda Loggning och diagnostik för Web Apps – med David Ebbo och strömmande loggar från webappar – 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 Hanselmans blogginlägg om ELMAH.

Du behöver inte heller använda ASP.NET eller System.Diagnostics spårning för att hämta strömmande loggar från Azure. App Service-appströmningsloggtjänsten strömmar alla .txt, .html eller .log fil som den hittar 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 hur du analyserar 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 McMurray om hur du använder LogParser
HTTP-statuskoden i IIS 7.0, IIS 7.5 och IIS 8.0

Analysera spårningsloggar för misslyckade begäranden

Microsoft TechNet-webbplatsen innehåller avsnittet Använda 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.

Dela via