Services bewaken en diagnosticeren in de ontwikkeling van lokale Linux-machines
Door services te bewaken, detecteren, diagnosticeren en problemen op te lossen, kunnen services de gebruikerservaring zo min mogelijk verstoren. Bewaking en diagnose zijn essentieel in een daadwerkelijk geïmplementeerde productieomgeving. Als u een vergelijkbaar model gebruikt tijdens de ontwikkeling van services, zorgt u ervoor dat de diagnostische pijplijn werkt wanneer u overstapt naar een productieomgeving. Service Fabric maakt het eenvoudig voor serviceontwikkelaars om diagnostische gegevens te implementeren die naadloos kunnen werken in zowel lokale ontwikkelconfiguraties met één machine als configuraties voor productieclusters in de echte wereld.
Fouten opsporen in Service Fabric Java-toepassingen
Voor Java-toepassingen zijn er meerdere frameworks voor logboekregistratie beschikbaar. Omdat java.util.logging dit de standaardoptie is met de JRE, wordt deze ook gebruikt voor de codevoorbeelden in GitHub. In de volgende discussie wordt uitgelegd hoe u het java.util.logging framework configureert.
Met behulp van java.util.logging kunt u uw toepassingslogboeken omleiden naar geheugen, uitvoerstromen, consolebestanden of sockets. Voor elk van deze opties zijn er al standaardhandlers beschikbaar in het framework. U kunt een app.properties bestand maken om de bestandshandler voor uw toepassing te configureren om alle logboeken om te leiden naar een lokaal bestand.
Het volgende codefragment bevat een voorbeeldconfiguratie:
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
De map waarnaar wordt verwezen door het app.properties bestand moet bestaan. Nadat het app.properties bestand is gemaakt, moet u ook het invoerpuntscript entrypoint.sh wijzigen in de <applicationfolder>/<servicePkg>/Code/ map om de eigenschap java.util.logging.config.file in te stellen op app.properties bestand. De vermelding moet eruitzien als het volgende fragment:
java -Djava.library.path=$LD_LIBRARY_PATH -Djava.util.logging.config.file=<path to app.properties> -jar <service name>.jar
Deze configuratie resulteert in logboeken die op een roterende manier worden verzameld./tmp/servicefabric/logs/ Het logboekbestand in dit geval heet mysfapp%u.%g.log waar:
- %u is een uniek getal om conflicten tussen gelijktijdige Java-processen op te lossen.
- %g is het generatienummer om onderscheid te maken tussen roterende logboeken.
Als er geen handler expliciet is geconfigureerd, wordt de consolehandler standaard geregistreerd. U kunt de logboeken in syslog bekijken onder /var/log/syslog.
Zie de codevoorbeelden in GitHub voor meer informatie.
Fouten opsporen in Service Fabric C#-toepassingen
Er zijn meerdere frameworks beschikbaar voor het traceren van CoreCLR-toepassingen in Linux. Zie .NET-extensies voor logboekregistratie voor meer informatie. Omdat EventSource bekend is met C#-ontwikkelaars, maakt dit artikel gebruik van EventSource voor tracering in CoreCLR-voorbeelden in Linux.
De eerste stap is het opnemen van System.Diagnostics.Tracing, zodat u uw logboeken kunt schrijven naar geheugen, uitvoerstromen of consolebestanden. Voor logboekregistratie met EventSource voegt u het volgende project toe aan uw project.json:
"System.Diagnostics.StackTrace": "4.0.1"
U kunt een aangepaste EventListener gebruiken om naar de service-gebeurtenis te luisteren en deze vervolgens op de juiste manier om te leiden naar traceringsbestanden. In het volgende codefragment ziet u een voorbeeld van een implementatie van logboekregistratie met behulp van EventSource en een aangepaste 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) : "");
}
}
}
}
Het voorgaande codefragment voert de logboeken uit naar een bestand in /tmp/MyServiceLog.txt. Deze bestandsnaam moet op de juiste wijze worden bijgewerkt. Als u de logboeken wilt omleiden naar de console, gebruikt u het volgende fragment in uw aangepaste EventListener-klasse:
public static TextWriter Out = Console.Out;
De voorbeelden in C# Samples gebruiken EventSource en een aangepaste EventListener om gebeurtenissen in een bestand te registreren.
Volgende stappen
Dezelfde traceringscode die aan uw toepassing is toegevoegd, werkt ook met de diagnostische gegevens van uw toepassing in een Azure-cluster. Bekijk deze artikelen waarin de verschillende opties voor de hulpprogramma's worden besproken en wordt beschreven hoe u deze kunt instellen.