Toepassingslogboeken

Het instrumenteren van uw code is niet alleen een manier om inzicht te krijgen in uw gebruikers, maar ook de enige manier om te weten of er iets mis is in uw toepassing en om vast te stellen wat er moet worden opgelost. Hoewel het technisch gezien mogelijk is om een foutopsporingsprogramma te verbinden met een productieservice, is dit niet gebruikelijk. Het is dus belangrijk om gedetailleerde instrumentatiegegevens te hebben.

Sommige producten instrumenteer uw code automatisch. Hoewel deze oplossingen goed kunnen werken, is handmatige instrumentatie bijna altijd vereist om specifiek te zijn voor uw bedrijfslogica. Uiteindelijk moet u voldoende informatie hebben om forensisch fouten in de toepassing op te sporen. Service Fabric-toepassingen kunnen worden geïnstrueerd met elk logboekframework. In dit document worden enkele verschillende benaderingen beschreven voor het instrumenteren van uw code en wanneer u de ene benadering boven de andere kunt kiezen.

Zie Logboekregistratie toevoegen aan uw Service Fabric-toepassing voor voorbeelden van het gebruik van deze suggesties.

Application Insights SDK

Application Insights heeft een uitgebreide integratie met Service Fabric. Gebruikers kunnen de AI Service Fabric nuget-pakketten toevoegen en gegevens en logboeken ontvangen die zijn gemaakt en verzameld en zichtbaar zijn in de Azure Portal. Daarnaast worden gebruikers aangemoedigd om hun eigen telemetrie toe te voegen om hun toepassingen te diagnosticeren en fouten op te sporen en bij te houden welke services en onderdelen van hun toepassing het meest worden gebruikt. De klasse TelemetryClient in de SDK biedt veel manieren om telemetrie in uw toepassingen bij te houden. Bekijk een voorbeeld van het instrumenteren en toevoegen van application insights aan uw toepassing in onze zelfstudie voor het bewaken en diagnosticeren van een .NET-toepassing

EventSource

Wanneer u een Service Fabric-oplossing maakt op basis van een sjabloon in Visual Studio, wordt er een van EventSource afgeleide klasse (ServiceEventSource of ActorEventSource) gegenereerd. Er wordt een sjabloon gemaakt waarin u gebeurtenissen voor uw toepassing of service kunt toevoegen. De EventSource-naammoet uniek zijn en de naam moet worden gewijzigd in de standaardsjabloontekenreeks MyCompany-solution-project<<>>. Het hebben van meerdere EventSource-definities die dezelfde naam gebruiken, veroorzaakt een probleem tijdens de uitvoering. Elke gedefinieerde gebeurtenis moet een unieke id hebben. Als een id niet uniek is, treedt er een runtimefout op. Sommige organisaties kennen vooraf waardenbereiken toe voor id's om conflicten tussen afzonderlijke ontwikkelteams te voorkomen. Zie de blog van Vance of de MSDN-documentatie voor meer informatie.

ASP.NET Core logboekregistratie

Het is belangrijk om zorgvuldig te plannen hoe u uw code gaat instrumenteert. Met het juiste instrumentatieplan kunt u voorkomen dat uw codebasis wordt gedestabiliseerd en de code vervolgens opnieuw moet worden geïnstrualiseerd. Om risico's te beperken, kunt u een instrumentatiebibliotheek zoals Microsoft.Extensions.Logging kiezen, die deel uitmaakt van Microsoft ASP.NET Core. ASP.NET Core heeft een ILogger-interface die u kunt gebruiken met de provider van uw keuze, terwijl het effect op bestaande code wordt geminimaliseerd. U kunt de code gebruiken in ASP.NET Core op Windows en Linux en in de volledige .NET Framework, zodat uw instrumentatiecode gestandaardiseerd is.

Volgende stappen

Zodra u uw logboekprovider hebt gekozen om uw toepassingen en services te instrumenteren, moeten uw logboeken en gebeurtenissen worden samengevoegd voordat ze naar een analyseplatform kunnen worden verzonden. Lees meer over Application Insights en EventFlow voor een beter inzicht in enkele van de aanbevolen opties van Azure Monitor.