Registo de aplicação

Instrumentar o código não é apenas uma forma de obter informações sobre os seus utilizadores, mas também a única forma de saber se algo está errado na sua aplicação e diagnosticar o que precisa de ser corrigido. Embora tecnicamente seja possível ligar um depurador a um serviço de produção, não é uma prática comum. Portanto, ter dados de instrumentação detalhados é importante.

Alguns produtos instrumentam automaticamente o seu código. Embora estas soluções possam funcionar bem, a instrumentação manual é quase sempre necessária para ser específica da sua lógica de negócio. No final, tem de ter informações suficientes para depurar a aplicação de forma forense. As aplicações do Service Fabric podem ser instrumentadas com qualquer arquitetura de registo. Este documento descreve algumas abordagens diferentes para instrumentar o seu código e quando escolher uma abordagem em vez de outra.

Para obter exemplos sobre como utilizar estas sugestões, veja Adicionar registo à sua aplicação do Service Fabric.

Application Insights SDK

O Application Insights tem uma integração avançada com o Service Fabric fora da caixa. Os utilizadores podem adicionar os pacotes nuget do AI Service Fabric e receber dados e registos criados e recolhidos visualizáveis no portal do Azure. Além disso, os utilizadores são encorajados a adicionar a sua própria telemetria para diagnosticar e depurar as suas aplicações e controlar quais os serviços e partes da sua aplicação que são mais utilizados. A classe TelemetryClient no SDK fornece várias formas de controlar a telemetria nas suas aplicações. Veja um exemplo de como instrumentar e adicionar informações de aplicações à sua aplicação no nosso tutorial para monitorizar e diagnosticar uma aplicação .NET

EventSource

Quando cria uma solução do Service Fabric a partir de um modelo no Visual Studio, é gerada uma classe derivada do EventSource (ServiceEventSource ou ActorEventSource). É criado um modelo, no qual pode adicionar eventos à sua aplicação ou serviço. O nome eventSourcetem de ser exclusivo e deve ser mudado a partir da cadeia de modelo predefinida MyCompany-solution-project<><>. Ter várias definições do EventSource que utilizam o mesmo nome causa um problema no tempo de execução. Cada evento definido tem de ter um identificador exclusivo. Se um identificador não for exclusivo, ocorrerá uma falha de runtime. Algumas organizações pré-atribuim intervalos de valores aos identificadores para evitar conflitos entre equipas de desenvolvimento separadas. Para obter mais informações, consulte o blogue do Vance ou a documentação do MSDN.

registo de ASP.NET Core

É importante planear cuidadosamente como vai instrumentar o seu código. O plano de instrumentação correto pode ajudá-lo a evitar potencialmente desestabilizar a base de código e, em seguida, a precisar de reinstalar o código. Para reduzir o risco, pode escolher uma biblioteca de instrumentação como Microsoft.Extensions.Logging, que faz parte do Microsoft ASP.NET Core. ASP.NET Core tem uma interface ILogger que pode utilizar com o fornecedor à sua escolha, ao mesmo tempo que minimiza o efeito no código existente. Pode utilizar o código no ASP.NET Core no Windows e Linux e na .NET Framework completa, para que o código de instrumentação seja padronizado.

Passos seguintes

Depois de ter escolhido o seu fornecedor de registos para instrumentar as suas aplicações e serviços, os seus registos e eventos têm de ser agregados antes de poderem ser enviados para qualquer plataforma de análise. Leia sobre o Application Insights e o EventFlow para compreender melhor algumas das opções recomendadas do Azure Monitor.