Monitorizar e diagnosticar serviços numa configuração local de desenvolvimento de máquina Linux

Monitorização, deteção, diagnóstico e resolução de problemas permitem que os serviços continuem com mínima perturbação na experiência do utilizador. A monitorização e o diagnóstico são críticos num ambiente de produção realmente implementado. Adotar um modelo semelhante durante o desenvolvimento dos serviços garante que o pipeline de diagnóstico funcionará quando se passa para um ambiente de produção. O Service Fabric facilita aos programadores de serviços a implementação de diagnósticos que podem funcionar de forma fluida tanto em configurações de desenvolvimento local de uma única máquina como em configurações reais de cluster de produção.

Depuração de aplicações Java no Service Fabric

Para aplicações Java, estão disponíveis múltiplos frameworks de registo. Como java.util.logging é a opção padrão do JRE, também é usada para os exemplos de código no GitHub. A discussão seguinte explica como configurar o java.util.logging framework.

Usando java.util.loging, pode redirecionar os registos da sua aplicação para memória, fluxos de saída, ficheiros de consola ou sockets. Para cada uma destas opções, já existem handlers padrão fornecidos no framework. Pode criar um app.properties ficheiro para configurar o gestor de ficheiros da sua aplicação para redirecionar todos os registos para um ficheiro local.

O seguinte excerto de código contém uma configuração de exemplo:

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 pelo app.properties ficheiro deve existir. Depois de o ficheiro app.properties ser criado, também precisa de modificar o seu script de inicialização, entrypoint.sh da pasta <applicationfolder>/<servicePkg>/Code/, para definir a propriedade java.util.logging.config.file para o ficheiro app.properties. A entrada deve assemelhar-se ao seguinte excerto:

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

Esta configuração resulta na recolha dos logs de forma rotativa em /tmp/servicefabric/logs/. O ficheiro de registo neste caso chama-se mysfapp%u.%g.log onde:

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

Por defeito, se nenhum handler estiver explicitamente configurado, o handler da consola é registado. Pode-se ver os logs no syslog em /var/log/syslog.

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

Depuração de aplicações Service Fabric em C#

Existem múltiplos frameworks disponíveis para rastrear aplicações CoreCLR no Linux. Para mais informações, consulte Extensões .NET para registo. Como o EventSource é familiar para os programadores de C#, este artigo utiliza o EventSource para rastreamento em amostras CoreCLR no Linux.

O primeiro passo é incluir System.Diagnostics.Tracing para que possa escrever os seus registos na memória, fluxos de saída ou ficheiros de consola. Para registar usando o EventSource, adicione o seguinte projeto ao seu project.json:

    "System.Diagnostics.StackTrace": "4.0.1"

Pode usar um EventListener personalizado para ouvir o evento de serviço e depois redirecioná-lo adequadamente para ficheiros de rastreamento. O seguinte excerto de código mostra uma implementação de exemplo de registo 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 excerto anterior regista os logs num ficheiro em /tmp/MyServiceLog.txt. Este nome de ficheiro precisa de ser devidamente atualizado. Caso queira redirecionar os logs para a consola, use o seguinte excerto na sua classe personalizada EventListener:

public static TextWriter Out = Console.Out;

Os samples em C# Samples utilizam o EventSource e um EventListener personalizado para registar eventos num ficheiro.

Próximos passos

O mesmo código de rastreamento adicionado à sua aplicação também funciona com o diagnóstico da sua aplicação num cluster Azure. Consulte estes artigos que discutem as diferentes opções para as ferramentas e descrevem como as configurar.

  • Last updated on