Programloggning

Instrumentering av din kod är inte bara ett sätt att få insikter om dina användare, utan också det enda sättet att veta om något är fel i ditt program och att diagnostisera vad som behöver åtgärdas. Även om det tekniskt sett är möjligt att ansluta ett felsökningsprogram till en produktionstjänst är det inte vanligt. Därför är det viktigt att ha detaljerade instrumentationsdata.

Vissa produkter instrumenterar koden automatiskt. Även om dessa lösningar kan fungera bra, krävs manuell instrumentering nästan alltid för att vara specifik för din affärslogik. I slutändan måste du ha tillräckligt med information för att felsöka programmet. Service Fabric-program kan instrumenteras med alla loggningsramverk. I det här dokumentet beskrivs några olika sätt att instrumentera koden och när du ska välja en metod framför en annan.

Exempel på hur du använder dessa förslag finns i Lägga till loggning i ditt Service Fabric-program.

Application Insights SDK

Application Insights har en omfattande integrering med Service Fabric direkt. Användare kan lägga till NUGET-paketen för AI Service Fabric och ta emot data och loggar som skapats och samlats in som kan visas i Azure Portal. Dessutom uppmanas användarna att lägga till sin egen telemetri för att diagnostisera och felsöka sina program och spåra vilka tjänster och delar av programmet som används mest. Klassen TelemetryClient i SDK innehåller många sätt att spåra telemetri i dina program. Ta en titt på ett exempel på hur du instrumenterar och lägger till application insights i ditt program i vår självstudie för övervakning och diagnostisering av ett .NET-program

EventSource

När du skapar en Service Fabric-lösning från en mall i Visual Studio genereras en EventSource-härledd klass (ServiceEventSource eller ActorEventSource). En mall skapas där du kan lägga till händelser för ditt program eller din tjänst. EventSource-namnetmåste vara unikt och bör byta namn från standardmallsträngen MyCompany-solution-project<<>>. Att ha flera EventSource-definitioner som använder samma namn orsakar ett problem vid körning. Varje definierad händelse måste ha en unik identifierare. Om en identifierare inte är unik uppstår ett körningsfel. Vissa organisationer förtilldelar intervall med värden för identifierare för att undvika konflikter mellan separata utvecklingsteam. Mer information finns i Vances blogg eller MSDN-dokumentationen.

ASP.NET Core loggning

Det är viktigt att noggrant planera hur du ska instrumentera koden. Rätt instrumenteringsplan kan hjälpa dig att undvika att potentiellt destabilisera kodbasen och sedan behöva instrumentera om koden. För att minska risken kan du välja ett instrumentationsbibliotek som Microsoft.Extensions.Logging, som är en del av Microsoft ASP.NET Core. ASP.NET Core har ett ILogger-gränssnitt som du kan använda med valfri leverantör, samtidigt som effekten på befintlig kod minimeras. Du kan använda koden i ASP.NET Core i Windows och Linux, och i den fullständiga .NET Framework, så att din instrumentationskod är standardiserad.

Nästa steg

När du har valt loggningsprovidern för att instrumentera dina program och tjänster måste dina loggar och händelser aggregeras innan de kan skickas till någon analysplattform. Läs mer om Application Insights och EventFlow för att bättre förstå några av de rekommenderade alternativen i Azure Monitor.