Monitorare e diagnosticare i servizi in una configurazione di sviluppo di computer Linux locale
Le operazioni di monitoraggio, rilevamento, diagnosi e risoluzione dei problemi consentono ai servizi di continuare a funzionare con un'interruzione minima dell'esperienza utente. Il monitoraggio e la diagnostica sono essenziali in un ambiente di produzione distribuito reale. L'adozione di un modello simile durante lo sviluppo dei servizi garantisce il funzionamento della pipeline di diagnostica anche in un ambiente di produzione. Service Fabric consente agli sviluppatori di servizi di implementare facilmente un sistema di diagnostica in grado di operare senza problemi sia in ambienti di sviluppo costituiti da un unico computer locale sia in configurazioni con cluster di produzione veri e propri.
Debug delle applicazioni Java di Service Fabric
Per le applicazioni Java sono disponibili più framework di registrazione . Poiché java.util.logging è l'opzione predefinita con JRE, viene usata anche per gli esempi di codice in GitHub. Di seguito viene illustrato come configurare il framework java.util.logging .
Usando java.util.logging è possibile reindirizzare i log dell'applicazione a memoria, flussi di output, file di console o socket. Nel framework sono disponibili gestori predefiniti per ognuna di queste opzioni. È possibile creare un file app.properties per configurare il gestore di file per l'applicazione in modo da reindirizzare tutti i log a un file locale.
Il frammento di codice seguente contiene una configurazione di esempio:
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
La cartella a cui fa riferimento il file app.properties deve essere presente. Dopo la creazione del file app.properties, è anche necessario modificare lo script del punto di ingressoentrypoint.sh, nella cartella <applicationfolder>/<servicePkg>/Code/ in modo da impostare la proprietà java.util.logging.config.file sul file app.properties. La voce dovrebbe essere simile al frammento seguente:
java -Djava.library.path=$LD_LIBRARY_PATH -Djava.util.logging.config.file=<path to app.properties> -jar <service name>.jar
Con questa configurazione, i log verranno raccolti a rotazione in /tmp/servicefabric/logs/. Il questo caso il file di log è denominato mysfapp%u.%g.log, dove:
- %u è un numero univoco per risolvere i conflitti tra processi simultanei di Java.
- %g è il numero di generazione per distinguere tra i log di rotazione.
Se non viene configurato in modo esplicito alcun gestore, per impostazione predefinita viene registrato il gestore della console. È possibile visualizzare i log in syslog, in /var/log/syslog.
Per altre informazioni, vedere gli esempi di codice in GitHub.
Debug di applicazioni C# di Service Fabric
Sono disponibili vari framework per il tracciamento delle applicazioni CoreCLR in Linux. Per altre informazioni, vedere Estensioni .NET per la registrazione. In questo articolo viene usato EventSource, già noto agli sviluppatori C#, per la traccia negli esempi CoreCLR in Linux.
Il primo passaggio consiste nell'includere System.Diagnostics.Tracing in modo da poter scrivere i log in m in memoria, flussi di output o file di console. Per la registrazione tramite EventSource, aggiungere il seguente progetto a project.json:
"System.Diagnostics.StackTrace": "4.0.1"
È possibile usare un EventListener personalizzato per l'ascolto dell'evento di servizio e quindi eseguire il reindirizzamento appropriato ai file di traccia. Il frammento di codice seguente mostra un esempio di implementazione della registrazione tramite EventSource e un EventListener personalizzato:
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) : "");
}
}
}
}
Il frammento di codice precedente restituisce i log a un file in /tmp/MyServiceLog.txt. Il nome del file deve essere aggiornato in modo appropriato. Se si desidera reindirizzare i log alla console, usare il frammento di codice seguente nella classe EventListener personalizzata:
public static TextWriter Out = Console.Out;
Gli esempi in C# Samples (Esempio C#) usano EventSource e un EventListener personalizzato per registrare eventi in un file.
Passaggi successivi
Lo stesso codice di traccia aggiunto all'applicazione potrà essere usato per la diagnostica dell'applicazione in un cluster di Azure. Consultare questi articoli che illustrano le diverse opzioni per gli strumenti e descrivono come configurarli.