Поделиться через

Мониторинг и диагностика сервисов в условиях разработки на локальной машине Linux

  • Статья

Мониторинг, обнаружение, диагностика и устранение неполадок позволяют службам продолжать работу с минимальным нарушением взаимодействия с пользователем. Мониторинг и диагностика критически важны в фактической развернутой рабочей среде. Внедрение аналогичной модели во время разработки служб гарантирует, что конвейер диагностики работает при переходе в рабочую среду. Service Fabric упрощает реализацию диагностики для разработчиков служб, которые могут легко работать как в локальных настройках разработки на одном компьютере, так и в реальных рабочих кластерах.

Отладка приложений Java Service Fabric

Для приложений Java доступны несколько платформ ведения журнала . Так как java.util.logging это параметр по умолчанию с JRE, он также используется для примеров кода в GitHub. В следующем обсуждении объясняется, как настроить платформу java.util.logging .

С помощью java.util.log можно перенаправить журналы приложений в память, выходные потоки, файлы консоли или сокеты. Для каждого из этих параметров в платформе уже предоставляются обработчики по умолчанию. Вы можете создать app.properties файл, чтобы настроить обработчик файлов для приложения, чтобы перенаправить все журналы в локальный файл.

Следующий фрагмент кода содержит пример конфигурации:

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

Папка, на которую указывает app.properties файл, должна существовать. После создания файла app.properties необходимо также изменить скрипт начальной точки entrypoint.sh в папке <applicationfolder>/<servicePkg>/Code/, чтобы задать свойство java.util.logging.config.file для файла app.properties. Запись должна выглядеть следующим фрагментом кода:

java -Djava.library.path=$LD_LIBRARY_PATH -Djava.util.logging.config.file=<path to app.properties> -jar <service name>.jar

Эта конфигурация приводит к сбору журналов по круговой схеме /tmp/servicefabric/logs/. Файл журнала в этом случае называется mysfapp%u.%g.log где:

  • %u — это уникальное число для устранения конфликтов между одновременными процессами Java.
  • %g — это номер поколения для различения вращающихся логов.

По умолчанию, если обработчик явно не настроен, обработчик консоли регистрируется. Журналы в системном журнале можно просмотреть в разделе /var/log/syslog.

Дополнительные сведения см. в примерах кода в GitHub.

Отладка приложений Service Fabric C#

Несколько платформ доступны для трассировки приложений CoreCLR в Linux. Дополнительные сведения см. в разделе "Расширения .NET для ведения журнала". Так как EventSource знаком разработчикам C#, эта статья использует EventSource для трассировки в примерах CoreCLR в Linux.

Первым шагом является включение System.Diagnostics.Tracing, чтобы вы могли записывать журналы в память, выходные потоки или файлы консоли. Для ведения журнала с помощью EventSource добавьте следующий проект в project.json:

    "System.Diagnostics.StackTrace": "4.0.1"

Вы можете использовать пользовательский слушатель событий, чтобы прослушивать событие службы, а затем соответствующим образом перенаправлять это событие в файлы трассировки. В следующем фрагменте кода показан пример реализации ведения журнала с помощью EventSource и настраиваемого объекта 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) : "");
                        }
                }
        }
}

Предыдущий фрагмент кода выводит логи в файл в /tmp/MyServiceLog.txt. Имя файла должно быть соответствующим образом обновлено. Если вы хотите перенаправить журналы в консоль, используйте следующий фрагмент кода в настроенном классе EventListener:

public static TextWriter Out = Console.Out;

Примеры на C# используют EventSource и настраиваемый EventListener для регистрации событий в файл.

Дальнейшие действия

Тот же код трассировки, добавленный в приложение, также работает с диагностикой приложения в кластере Azure. Ознакомьтесь с этими статьями, которые обсуждают различные варианты инструментов и описывают их настройку.