Partilhar via

Monitorar e diagnosticar serviços em uma configuração local de desenvolvimento de máquinas Linux

  • Artigo

O monitoramento, a deteção, o diagnóstico e a solução de problemas permitem que os serviços continuem com o mínimo de interrupção na experiência do usuário. O monitoramento e o diagnóstico são essenciais em um ambiente de produção real implantado. A adoção de um modelo semelhante durante o desenvolvimento de serviços garante que o pipeline de diagnóstico funcione quando você se move para um ambiente de produção. O Service Fabric facilita para os desenvolvedores de serviços a implementação de diagnósticos que podem funcionar perfeitamente em configurações de desenvolvimento local de máquina única e configurações de cluster de produção do mundo real.

Depurando aplicativos Java do Service Fabric

Para aplicações Java, várias estruturas de log estão disponíveis. Como java.util.logging é a opção padrão com o JRE, ela também é usada para os exemplos de código no GitHub. A discussão a seguir explica como configurar a java.util.logging estrutura.

Usando java.util.logging, você pode redirecionar os logs do aplicativo para memória, fluxos de saída, arquivos de console ou soquetes. Para cada uma dessas opções, há manipuladores padrão já fornecidos na estrutura. Você pode criar um app.properties arquivo para configurar o manipulador de arquivos para seu aplicativo para redirecionar todos os logs para um arquivo local.

O trecho de código a seguir contém um exemplo de configuração:

handlers = java.util.logging.FileHandler

java.util.logging.FileHandler.level = ALL
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
java.util.logging.FileHandler.limit = 1024000
java.util.logging.FileHandler.count = 10
java.util.logging.FileHandler.pattern = /tmp/servicefabric/logs/mysfapp%u.%g.log

A pasta apontada app.properties pelo arquivo deve existir. Depois que o app.properties arquivo é criado, você também precisa modificar seu script de <applicationfolder>/<servicePkg>/Code/ ponto de entrada, entrypoint.sh na pasta para definir a propriedade java.util.logging.config.file como app.properties arquivo. A entrada deve se parecer com o seguinte trecho:

java -Djava.library.path=$LD_LIBRARY_PATH -Djava.util.logging.config.file=<path to app.properties> -jar <service name>.jar

Essa configuração resulta em logs sendo coletados de forma rotativa em /tmp/servicefabric/logs/. O arquivo de log, neste caso, é nomeado mysfapp%u.%g.log onde:

  • %u é um número exclusivo para resolver conflitos entre processos Java simultâneos.
  • %g é o número de geração para distinguir entre logs rotativos.

Por padrão, se nenhum manipulador estiver explicitamente configurado, o manipulador de console será registrado. Pode-se visualizar os logs no syslog em /var/log/syslog.

Para obter mais informações, consulte os exemplos de código no GitHub.

Depurando aplicativos C# do Service Fabric

Várias estruturas estão disponíveis para rastrear aplicativos CoreCLR no Linux. Para obter mais informações, consulte Extensões .NET para registro em log. Como o EventSource é familiar para desenvolvedores de C#, este artigo usa EventSource para rastreamento em exemplos CoreCLR no Linux.

A primeira etapa é incluir System.Diagnostics.Tracing para que você possa gravar seus logs na memória, fluxos de saída ou arquivos de console. Para registrar em log usando EventSource, adicione o seguinte projeto ao seu project.json:

    "System.Diagnostics.StackTrace": "4.0.1"

Você pode usar um EventListener personalizado para ouvir o evento de serviço e, em seguida, redirecioná-los adequadamente para rastrear arquivos. O trecho de código a seguir mostra uma implementação de exemplo de log usando EventSource e um EventListener personalizado:


public class ServiceEventSource : EventSource
{
        public static ServiceEventSource Current = new ServiceEventSource();

        [NonEvent]
        public void Message(string message, params object[] args)
        {
            if (this.IsEnabled())
            {
                var finalMessage = string.Format(message, args);
                this.Message(finalMessage);
            }
        }

        // TBD: Need to add method for sample event.

}


internal class ServiceEventListener : EventListener
{

        protected override void OnEventSourceCreated(EventSource eventSource)
        {
            EnableEvents(eventSource, EventLevel.LogAlways, EventKeywords.All);
        }
        protected override void OnEventWritten(EventWrittenEventArgs eventData)
        {
                using (StreamWriter Out = new StreamWriter( new FileStream("/tmp/MyServiceLog.txt", FileMode.Append)))
                {
                        // report all event information
                        Out.Write(" {0} ", Write(eventData.Task.ToString(), eventData.EventName, eventData.EventId.ToString(), eventData.Level,""));
                        if (eventData.Message != null)
                                Out.WriteLine(eventData.Message, eventData.Payload.ToArray());
                        else
                        {
                                string[] sargs = eventData.Payload != null ? eventData.Payload.Select(o => o.ToString()).ToArray() : null; 
                                Out.WriteLine("({0}).", sargs != null ? string.Join(", ", sargs) : "");
                        }
                }
        }
}

O trecho anterior gera os logs para um arquivo no /tmp/MyServiceLog.txt. Esse nome de arquivo precisa ser atualizado adequadamente. Caso você queira redirecionar os logs para o console, use o seguinte trecho em sua classe EventListener personalizada:

public static TextWriter Out = Console.Out;

Os exemplos em C# Samples usam EventSource e um EventListener personalizado para registrar eventos em um arquivo.

Próximos passos

O mesmo código de rastreamento adicionado ao seu aplicativo também funciona com o diagnóstico do seu aplicativo em um cluster do Azure. Confira estes artigos que discutem as diferentes opções para as ferramentas e descrevem como configurá-las.