Элементы диагностики

Настройка уровней логирования

Вы можете настроить уровни логирования для всех сервисов.

Возможны следующие конфигурации логирования для каждого сервиса:

  • Глобальный - устанавливается в конфигурации сервиса (действует всегда).

  • Локальный - устанавливается/удаляется в swagger узла в разделе Settings. По умолчанию у сервисов нет локального конфигурации.

  • Итоговый - конфигурация, которая фактически работает в Платформе. Определяется сравнением глобальной конфигурации с локальной. Выбираются более подробные(точные) настройки из двух.

Внимание

Итоговая конфигурация сервиса сравнивается с итоговой конфигурацией кластера. Финальная настройка определяется также - выбирается более точные настройки из двух. То есть, если итоговая конфигурация в кластере с уровнем Debug, то у всех его сервисов будет уровень логирования не ниже Debug, но если у узла, например, уровень выше - Verbose, то будет у узла работать Verbose как более подробный. При принятии решения о логировании также учитывается переданная функциональность (по умолчанию ALL). Если уровень логирования ниже минимального, но итоговая конфигурация содержит переданную функциональность, то лог будет записан. Список функциональностей итоговой конфигурации формируется как объединение локальных, глобальных и функциональностей кластера.

Уровни логирования следующие: Verbose, Debug, Info, Warning, Error, Fatal.

Разделение логов по функциональности:

  • All - все подряд = значение по умолчанию;

  • NodeStorage - работа с сообщениями и БД на узле;

  • ProcessBalancing - Балансировка процессов;

  • Coordinator - пинги координатора и прочее;

  • Connections - логи от tcp\pipe;

  • Diagnostic - диагностика;

  • Apply - логи apply;

  • Custom - логи пользователя.

Пример использования:

  • На кластере установлен уровень логирования Info (Глобальная конфигурация кластера). Локальный не установлен для кластера.

  • На адаптере установлен уровень логирования Warning (Глобальная конфигурация системы). Локальный не установлен для адаптера.

Нам понадобилось отладить адаптер и нужны более подробные логи на время:

  1. Устанавливаем уровень логирования Verbose в локальной конфигурации адаптера и применяем конфигурацию: post/api/settings/systems/{EntityId}/local

  2. Получаем логи у адаптера с уровнем Verbose.

  3. Закончив работу, удаляем локальную конфигурацию адаптера: delete/api/settings/systems/{EntityId}/local

Просмотр цепочки событий

Для графического представления пути передачи и обработки сообщения в Платформу автоматически строится Цепочка событий. Цепочка событий представляет собой блок-схему этапов передачи сообщения с возможностью просмотра подробной информации о событии. На вертикальной оси блок-схемы отображается время события, на горизонтальной оси отображены сервисы Платформы, участвующие в событии:

../../_images/image1161.png

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

../../_images/image1171.png
../../_images/image1181.png

В некоторых блоках в левом верхнем углу активен значок информации. После наведения на значок информации отображается краткая информация о событии:

../../_images/image1191.png

Для Цепочки информации работает фильтр по уровню логирования:

../../_images/image120.png

События регистрируемые в банке данных

Тип события Write для Банка данных

Если процесс содержит шаг запись объекта, то в цепочке событий будет отображено событие типа Write.

Пример:

../../_images/image1211.png

Тип события Read

Если процесс содержит шаги Поиск, получение объекта, получение Объектов, то в цепочке событий будет отображено событие типа Read.

Пример:

../../_images/image1221.png

Тип события Delete

Если процесс содержит шаг Удаление, то в цепочке событий будет отображено событие типа Delete.

Пример:

../../_images/image1231.png

Тип события Query

Если процесс содержит шаги запрос, запрос значений, запрос объекта, то в цепочке событий будет отображено событие типа Query.

Пример:

../../_images/image1241.png

Просмотр данных очередей

Просмотр данных очередей Платформы возможен с помощью следующих инструментов:

  • Центр мониторинга и администрирования и диагностики.

  • Сервисная утилита DatareonQueueViewer.

Центр мониторинга и администрирования и диагностики

Сайт публикуется автоматически на узле-координаторе. По умолчанию используется порт 7201. Со всех остальных узлов выполняется автоматическое перенаправление. Просмотр данных очередей возможен непосредственно при работе системы. Для очереди формируется snapshot и возвращается пользователю. Соответственно на момент просмотра пользователем snapshot данные в очередях могут меняться.

Сервисная утилита DatareonQueueViewer

Сервисная утилита используется для просмотра данных очередей в каталоге узла при выключенной системе.

Утилита DatareonQueueViewer.exe устанавливается вместе с дистрибутивом и размещается в установочном каталоге Платформы. Запись лога выполняется в каталог %appdata%\local\Datareon\Platform\Logs\DatareonQueueViewer.

Функция сжатия очередей

Команда compress для DatareonPlatformService.exe. Без опций сжимает весь каталог с очередями.

Опции:

  • id <ид_очереди> - сжимает конкретную очередь.

  • backup true/false - создает или не создает бекап исходных каталогов. По умолчанию true.

  • rootPath - опциональный каталог с данными Platform для случая, когда нужно сжать файлы в каталоге, отличном от установленного по умолчанию C:\ProgramData\Datareon\Platform. В случае указания не производится проверка активности службы. При включенной службе будет ошибка о том, что служба платформы активна. Исходные очереди сохраняются в каталог с наименованием old.

../../_images/image1251.png

Логи дублируются в каталог:

C:\ProgramData\Datareon\Platform\Logs\DatareonPlatformService\CmdDebug