Monitorowanie i diagnozowanie usług w lokalnej konfiguracji tworzenia maszyny z systemem Linux
Monitorowanie, wykrywanie, diagnozowanie i rozwiązywanie problemów umożliwiają usługom kontynuowanie minimalnych zakłóceń w środowisku użytkownika. Monitorowanie i diagnostyka są krytyczne 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 pracować 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 struktur rejestrowania . Ponieważ java.util.logging jest to domyślna opcja ś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ć java.util.logging strukturę.
Za pomocą pliku java.util.logging można przekierować dzienniki aplikacji do pamięci, strumieni wyjściowych, plików konsoli lub gniazd. Dla każdej z tych opcji są już dostępne domyślne programy obsługi. 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 poniższego 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 obrotowy w lokalizacji /tmp/servicefabric/logs/. Plik dziennika w tym przypadku nosi nazwę mysfapp%u.%g.log, gdzie:
- %u jest unikatową liczbą, która umożliwia rozwiązywanie konfliktów między równoczesnymi procesami Języka Java.
- %g jest numerem generacji, który umożliwia rozróżnienie między obracającymi się 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 systemowym w obszarze /var/log/syslog.
Aby uzyskać więcej informacji, zobacz przykłady kodu w usłudze GitHub.
Debugowanie aplikacji 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 pliku 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 elementu 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 współ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.