Monitorowanie i diagnozowanie usług w lokalnej konfiguracji tworzenia maszyn z systemem Linux
Monitorowanie, wykrywanie, diagnozowanie i rozwiązywanie problemów umożliwiają korzystanie z usług w celu kontynuowania minimalnej zakłóceń w środowisku użytkownika. Monitorowanie i diagnostyka mają krytyczne znaczenie w rzeczywistym wdrożonym środowisku produkcyjnym. Wdrożenie podobnego modelu podczas opracowywania usług gwarantuje, że potok diagnostyczny działa po przejściu do środowiska produkcyjnego. Usługa Service Fabric ułatwia deweloperom usług implementowanie diagnostyki, która może bezproblemowo działać zarówno w ramach konfiguracji programowania lokalnego pojedynczego komputera, jak i rzeczywistych konfiguracji klastra produkcyjnego.
Debugowanie aplikacji Java usługi Service Fabric
W przypadku aplikacji Java dostępnych jest wiele platform rejestrowania. Ponieważ java.util.logging jest to opcja domyślna środowiska JRE, jest ona również używana dla przykładów kodu w usłudze GitHub. W poniższej dyskusji wyjaśniono, jak skonfigurować platformę java.util.logging .
Za pomocą pliku java.util.logging można przekierowywać dzienniki aplikacji do pamięci, strumieni wyjściowych, plików konsoli lub gniazd. Dla każdej z tych opcji istnieją już domyślne programy obsługi dostępne w strukturze. Możesz utworzyć app.properties plik w celu skonfigurowania programu obsługi plików dla aplikacji w celu przekierowania wszystkich dzienników do pliku lokalnego.
Poniższy fragment kodu zawiera przykładową konfigurację:
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
Folder wskazywany przez app.properties plik musi istnieć. Po utworzeniu app.properties pliku należy również zmodyfikować skrypt punktu wejścia w folderze<applicationfolder>/<servicePkg>/Code/, entrypoint.sh aby ustawić właściwość java.util.logging.config.file na app.properties plik. Wpis powinien wyglądać podobnie do następującego fragmentu kodu:
java -Djava.library.path=$LD_LIBRARY_PATH -Djava.util.logging.config.file=<path to app.properties> -jar <service name>.jar
Ta konfiguracja powoduje zbieranie dzienników w sposób rotacyjny w witrynie /tmp/servicefabric/logs/. Plik dziennika w tym przypadku nosi nazwę mysfapp%u.%g.log gdzie:
- %u to unikatowa liczba umożliwiająca rozwiązywanie konfliktów między równoczesnym procesami języka Java.
- %g to numer generacji do odróżnienia między rotacyjnymi dziennikami.
Domyślnie, jeśli program obsługi nie jest jawnie skonfigurowany, program obsługi konsoli jest zarejestrowany. Dzienniki można wyświetlić w dzienniku syslog w obszarze /var/log/syslog.
Aby uzyskać więcej informacji, zobacz przykłady kodu w usłudze GitHub.
Debugowanie aplikacji w języku C# usługi Service Fabric
Wiele platform jest dostępnych do śledzenia aplikacji CoreCLR w systemie Linux. Aby uzyskać więcej informacji, zobacz .NET Extensions for Logging (Rozszerzenia platformy .NET na potrzeby rejestrowania). Ponieważ usługa EventSource jest znana deweloperom języka C#, w tym artykule użyto usługi EventSource do śledzenia w przykładach CoreCLR w systemie Linux.
Pierwszym krokiem jest dołączenie elementu System.Diagnostics.Tracing, dzięki czemu można zapisywać dzienniki w pamięci, strumieniach wyjściowych lub plikach konsoli. W przypadku rejestrowania przy użyciu usługi EventSource dodaj następujący projekt do project.json:
"System.Diagnostics.StackTrace": "4.0.1"
Możesz użyć niestandardowego elementu EventListener, aby nasłuchiwać zdarzenia usługi, a następnie odpowiednio przekierować je do plików śledzenia. Poniższy fragment kodu przedstawia przykładową implementację rejestrowania przy użyciu usługi EventSource i niestandardowego elementu 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) : "");
}
}
}
}
Powyższy fragment kodu zwraca dzienniki do pliku w pliku w /tmp/MyServiceLog.txtpliku . Ta nazwa pliku musi zostać odpowiednio zaktualizowana. Jeśli chcesz przekierować dzienniki do konsoli, użyj następującego fragmentu kodu w dostosowanej klasie EventListener:
public static TextWriter Out = Console.Out;
Przykłady w przykładach w języku C# używają elementu EventSource i niestandardowego elementu EventListener do rejestrowania zdarzeń w pliku.
Następne kroki
Ten sam kod śledzenia dodany do aplikacji działa również z diagnostyką aplikacji w klastrze platformy Azure. Zapoznaj się z tymi artykułami, które omawiają różne opcje narzędzi i opisują sposób ich konfigurowania.