Share via

Övervaka och diagnostisera tjänster i en lokal installation av Linux-datorer

  • Artikel

Övervakning, identifiering, diagnostisering och felsökning gör det möjligt för tjänster att fortsätta med minimala störningar i användarupplevelsen. Övervakning och diagnostik är viktiga i en faktisk distribuerad produktionsmiljö. Om du använder en liknande modell under utvecklingen av tjänster ser du till att diagnostikpipelinen fungerar när du flyttar till en produktionsmiljö. Service Fabric gör det enkelt för tjänstutvecklare att implementera diagnostik som sömlöst kan fungera i både lokala utvecklingskonfigurationer för en enskild dator och konfigurationer av verkliga produktionskluster.

Felsöka Service Fabric Java-program

För Java-program är flera loggningsramverk tillgängliga. Eftersom java.util.logging är standardalternativet med JRE används det också för kodexemplen i GitHub. I följande diskussion förklaras hur du konfigurerar ramverket java.util.logging .

Med java.util.logging kan du omdirigera programloggarna till minne, utdataströmmar, konsolfiler eller socketar. För vart och ett av dessa alternativ finns det standardhanterare som redan finns i ramverket. Du kan skapa en app.properties fil för att konfigurera filhanteraren för ditt program för att omdirigera alla loggar till en lokal fil.

Följande kodfragment innehåller en exempelkonfiguration:

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

Mappen som filen pekar på app.properties måste finnas. app.properties När filen har skapats måste du också ändra startpunktsskriptet entrypoint.sh i <applicationfolder>/<servicePkg>/Code/ mappen för att ange egenskapen java.util.logging.config.file till app.properties fil. Posten bör se ut som följande kodfragment:

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

Den här konfigurationen resulterar i att loggar samlas in på ett roterande sätt på /tmp/servicefabric/logs/. Loggfilen i det här fallet heter mysfapp%u.%g.log där:

  • %u är ett unikt tal för att lösa konflikter mellan samtidiga Java-processer.
  • %g är det generationsnummer som ska skilja mellan roterande loggar.

Om ingen hanterare har konfigurerats explicit registreras konsolhanteraren som standard. Man kan visa loggarna i syslog under /var/log/syslog.

Mer information finns i kodexemplen i GitHub.

Felsöka Service Fabric C#-program

Flera ramverk är tillgängliga för spårning av CoreCLR-program i Linux. Mer information finns i .NET-tillägg för loggning. Eftersom EventSource är bekant för C#-utvecklare använder den här artikeln EventSource för spårning i CoreCLR-exempel i Linux.

Det första steget är att inkludera System.Diagnostics.Tracing så att du kan skriva loggarna till minne, utdataströmmar eller konsolfiler. För loggning med EventSource lägger du till följande projekt i project.json:

    "System.Diagnostics.StackTrace": "4.0.1"

Du kan använda en anpassad EventListener för att lyssna efter tjänsthändelsen och sedan omdirigera dem till spårningsfiler på rätt sätt. Följande kodfragment visar en exempelimplementering av loggning med EventSource och en anpassad EventListener:


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) : "");
                        }
                }
        }
}

Föregående kodfragment matar ut loggarna till en fil i /tmp/MyServiceLog.txt. Det här filnamnet måste uppdateras på rätt sätt. Om du vill omdirigera loggarna till konsolen använder du följande kodfragment i din anpassade EventListener-klass:

public static TextWriter Out = Console.Out;

Exemplen på C#-exempel använder EventSource och en anpassad EventListener för att logga händelser till en fil.

Nästa steg

Samma spårningskod som läggs till i ditt program fungerar också med diagnostiken för ditt program i ett Azure-kluster. Läs de här artiklarna som beskriver de olika alternativen för verktygen och beskriver hur du konfigurerar dem.