Services bewaken en diagnosticeren in een lokale installatie van linux-machineontwikkeling
Met bewaking, detectie, diagnose en probleemoplossing kunnen services doorgaan met minimale onderbreking van de gebruikerservaring. 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 naar een productieomgeving overstapt. Service Fabric maakt het eenvoudig voor serviceontwikkelaars om diagnostische gegevens te implementeren die naadloos kunnen werken in zowel lokale ontwikkelinstellingen met één machine als echte productieclusterconfiguraties.
Fouten opsporen in Service Fabric Java-toepassingen
Voor Java-toepassingen zijn meerdere frameworks voor logboekregistratie beschikbaar. Omdat java.util.logging de standaardoptie voor de JRE is, 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 zo te configureren dat alle logboeken naar een lokaal bestand worden omgeleid.
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 door het app.properties bestand wordt verwezen, 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 codefragment:
java -Djava.library.path=$LD_LIBRARY_PATH -Djava.util.logging.config.file=<path to app.properties> -jar <service name>.jar
Deze configuratie resulteert in het verzamelen van logboeken op een roterende manier op /tmp/servicefabric/logs/. Het logboekbestand heet in dit geval mysfapp%u.%g.log, waarbij:
- %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.
Foutopsporing in Service Fabric C#-toepassingen
Er zijn meerdere frameworks beschikbaar voor het traceren van CoreCLR-toepassingen in Linux. Zie .NET Extensions for Logging (.NET-extensies voor logboekregistratie) voor meer informatie. Omdat EventSource bekend is bij 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 te luisteren naar de service-gebeurtenis en deze vervolgens op de juiste manier omleiden om bestanden te traceren. 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 fragment voert de logboeken uit naar een bestand in /tmp/MyServiceLog.txt. Deze bestandsnaam moet op de juiste manier worden bijgewerkt. Als u de logboeken naar de console wilt omleiden, gebruikt u het volgende fragment in uw aangepaste EventListener-klasse:
public static TextWriter Out = Console.Out;
De voorbeelden in C#-voorbeelden gebruiken EventSource en een aangepaste EventListener om gebeurtenissen in een bestand te registreren.
Volgende stappen
Dezelfde traceringscode die is toegevoegd aan uw toepassing, 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 instelt.