Share via

Monitorování a diagnostika služeb v nastavení vývoje místního počítače s Linuxem

  • Článek

Monitorování, zjišťování, diagnostika a řešení potíží umožňují, aby služby pokračovaly s minimálním přerušením uživatelského prostředí. Monitorování a diagnostika jsou kritické ve skutečně nasazených produkčních prostředích. Přijetí podobného modelu během vývoje služeb zajistí, že při přechodu do produkčního prostředí bude diagnostický kanál fungovat. Service Fabric usnadňuje vývojářům služeb implementaci diagnostiky, která může bezproblémově pracovat jak v nastaveních místního vývoje na jednom počítači, tak i v reálných nastaveních produkčních clusterů.

Ladění aplikací Service Fabric v Javě

Pro aplikace v Javě je k dispozici několik rozhraní protokolování . Vzhledem k tomu java.util.logging , že je výchozí možnost pro JRE, používá se také pro příklady kódu v GitHubu. Následující diskuze vysvětluje, jak architekturu java.util.logging nakonfigurovat.

Pomocí java.util.logging můžete protokoly aplikace přesměrovat do paměti, výstupních datových proudů, souborů konzoly nebo soketů. Pro každou z těchto možností jsou v architektuře již k dispozici výchozí obslužné rutiny. Můžete vytvořit soubor, který app.properties nakonfiguruje obslužnou rutinu souboru pro vaši aplikaci tak, aby přesměrovává všechny protokoly do místního souboru.

Následující fragment kódu obsahuje ukázkovou konfiguraci:

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

Složka, na kterou app.properties soubor odkazuje, musí existovat. app.properties Po vytvoření souboru musíte také upravit skript vstupního <applicationfolder>/<servicePkg>/Code/ bodu ve složce a entrypoint.sh nastavit vlastnost java.util.logging.config.file na app.properties soubor. Položka by měla vypadat jako v následujícím fragmentu kódu:

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

Výsledkem této konfigurace je, že se protokoly shromažďují rotujícím způsobem v nástroji /tmp/servicefabric/logs/. Soubor protokolu má v tomto případě název mysfapp%u.%g.log, kde:

  • %u je jedinečné číslo pro řešení konfliktů mezi současnými procesy Java.
  • %g je číslo generování pro rozlišení mezi rotujícími protokoly.

Pokud není explicitně nakonfigurovaná žádná obslužná rutina, je ve výchozím nastavení zaregistrována obslužná rutina konzoly. Protokoly v syslogu můžete zobrazit v souboru /var/log/syslog.

Další informace najdete v příkladech kódu na GitHubu.

Ladění aplikací Service Fabric v jazyce C#

Pro trasování aplikací CoreCLR v Linuxu je k dispozici několik architektur. Další informace najdete v tématu Rozšíření .NET pro protokolování. Vzhledem k tomu, že eventSource znají vývojáři v C#, používá tento článek EventSource k trasování v ukázkách CoreCLR v Linuxu.

Prvním krokem je zahrnout System.Diagnostics.Tracing, abyste mohli protokoly zapisovat do paměti, výstupních datových proudů nebo souborů konzoly. Pokud chcete protokolovat pomocí EventSource, přidejte do souboru project.json následující projekt:

    "System.Diagnostics.StackTrace": "4.0.1"

K naslouchání události služby můžete použít vlastní eventListener a pak je odpovídajícím způsobem přesměrovat na soubory trasování. Následující fragment kódu ukazuje ukázkovou implementaci protokolování pomocí EventSource a vlastního eventListeneru:


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

Předchozí fragment kódu vypíše protokoly do souboru v /tmp/MyServiceLog.txt. Tento název souboru je potřeba odpovídajícím způsobem aktualizovat. Pokud chcete protokoly přesměrovat do konzoly, použijte následující fragment kódu v přizpůsobené třídě EventListener:

public static TextWriter Out = Console.Out;

Ukázky v C# Samples používají k protokolování událostí do souboru eventSource a vlastní EventListener.

Další kroky

Stejný kód trasování přidaný do vaší aplikace funguje také s diagnostikou vaší aplikace v clusteru Azure. Podívejte se na tyto články, které popisují různé možnosti nástrojů a popisují, jak je nastavit.