Конфигурирование ведения журнала

Определение модели ThingWorx в Composer > Система > Журналы > Конфигурирование ведения журнала

Стандартный файл internal-logback.xml по умолчанию является частью файла ThingWorx .war и используется для конфигурирования подсистемы logback. Чтобы найти файл, распакуйте файл Thingworx.war, а затем распакуйте WEB_INF/lib/thingworx-platform-common-[номер_версии].jar.

Вы можете скопировать internal-logback.xml в /ThingworxPlatform/logback.xml и внести изменения. Эти файлы logback.xml не помещаются или не наследуются друг от друга. Затем можно поместить обновленный файл в папку конфигурации ThingWorx default/ThingworxPlatform для каждого экземпляра ThingWorx.

Изменение уровня ведения журнала на DEBUG

Вы можете изменить запись, чтобы принудительно задать для журнала конкретного класса уровень DEBUG. Например, можно изменить следующий код:

на код, содержащий level="DEBUG":

Или можно добавить новую запись с конкретным уровнем журнала. Например:

Запись уровня пакета, подобная этой, включает ведение журнала для этого пакета и подпакетов.

Аппендеры

Можно указать, в каком журнале должна отображаться информация, указав правильный аппендер как <appender-ref ref="[имя аппендера]"/>. Возможные аппендеры:

• ASYNC_APPENDER_CONSOLE - вывод в консоли

• ASYNC_APPENDER_APPLICATION - журнал приложений

• ASYNC_APPENDER_ERROR - журнал ошибок

• ASYNC_APPENDER_SECURITY - журнал безопасности

• ASYNC_APPENDER_SCRIPT - журнал сценариев

• ASYNC_APPENDER_SCRIPT_ERROR - журнал ошибок сценариев

• ASYNC_APPENDER_CONFIGURATION - журнал конфигурации

• ASYNC_APPENDER_DATABASE - журнал базы данных

• ASYNC_APPENDER_COMMUNICATION - журнал взаимодействия

Асинхронный аппендер

ThingWorx использует библиотеку ведения журналов logback с помощью аппендера консоли и последовательного аппендера файлов. Оба аппендера входят в асинхронный аппендер, который отсоединяет инициаторы запроса журнала от фактических записей в журнал. Инициаторы запроса журнала вызывают метод append(logEvent) на AsyncAppender. Этот метод добавляет logEvent к внутренней очереди в AsyncAppender. Поэтому инициатор запроса журнала может продолжать свою работу, не дожидаясь записи logEvent в целевую консоль или в файл. В AsyncAppender внутренний поток выбирает самое старое событие logEvent из внутренней очереди и вызывает append(LogEvent) на консоли или в файле, содержащих аппендер журнала. Внутренняя очередь также служит буфером, что предотвращает потерю данных во время коротких всплесков активности, когда инициаторы запросов к журналу превышают внутреннюю скорость записи аппендера.Дополнительные сведения см. в документе https://logback.qos.ch/manual/appenders.html (на английском языке).

В файле logback.xml можно сконфигурировать следующие параметры AsyncAppender:

Параметр	Переменная среды	Базовый тип	По умолчанию	Описание
queueSize	Различается для каждого AsyncAppender; см. таблицу ниже	INTEGER	256	Максимальная емкость очереди блокировки. Это значение используется во время создания AsyncAppender и не может быть изменено. Это значение может быть задано для каждого аппендера.
discardingThreshold	DISCARDING_THRESHOLD	INTEGER	0%	По умолчанию, когда остается 20 % от емкости очереди блокировки, она будет отбрасывать события с уровнями TRACE, DEBUG и INFO и сохранять события с уровнями WARN и ERROR. Чтобы сохранять все события, задайте для discardingThreshold значение 0.
maxFlushTime	MAX_FLUSH_TIME	INTEGER	1000 мс	Максимальный тайм-аут очистки очереди в миллисекундах. В зависимости от глубины и задержки очереди относительно привязанного аппендера для AsyncAppender может потребоваться неприемлемо большое время для полной очистки очереди. Когда LoggerContext остановлен, метод остановки AsyncAppender ожидает в течение этого времени завершения рабочего потока. События, которые не могут быть обработаны в это время, будут потеряны. Семантика этого значения идентична параметрам Thread.join(long).
neverBlock	NEVER_BLOCK	BOOLEAN	false	По умолчанию для этого параметра задано значение false; это означает, что аппендер будет блокировать добавление к полной очереди, а не отбрасывать сообщение. Если для этого свойства задано значение true, аппендер будет отбрасывать сообщение, а не блокировать приложение.

Значения размера очереди для асинхронных аппендеров

Каждый AsyncAppender имеет собственное значение для , поскольку средства ведения журнала будут иметь разные нагрузки и им требуются различные размеры очереди.
Наименование аппендера	Переменная среды	По умолчанию
ASYNC_APPENDER_APPLICATION	MAX_QUEUE_SIZE_APPLICATION	10000
ASYNC_APPENDER_CONSOLE	ASYNC_APPENDER_CONSOLE	10000
ASYNC_APPENDER_CONFIGURATION	MAX_QUEUE_SIZE_CONFIGURATION	1000
ASYNC_APPENDER_SECURITY	MAX_QUEUE_SIZE_SECURITY	1000
ASYNC_APPENDER_DATABASE	MAX_QUEUE_SIZE_DATABASE	1000
ASYNC_APPENDER_COMMUNICATION	MAX_QUEUE_SIZE_COMMUNICATION	1000
ASYNC_APPENDER_ERROR	MAX_QUEUE_SIZE_ERROR	5000
ASYNC_APPENDER_SCRIPT	MAX_QUEUE_SIZE_SCRIPT	5000
ASYNC_APPENDER_SCRIPT_ERROR	MAX_QUEUE_SIZE_SCRIPT_ERROR	5000

Можно изменить значения по умолчанию, задавая соответствующую переменную среды. При выполнении сервера в Eclipse необходимо задать переменные среды в Run configuration/server/environment.

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

Настройки журнала

Ниже приведены настройки конфигурации logback по умолчанию для последовательных файлов и архивации. Эти настройки можно сконфигурировать в Composer в разделе Подсистемы > LoggingSubsystem > Конфигурация > Настройки сохранения журнала.

Настройка сохранения журнала	Имя свойства	По умолчанию	Описание
Макс. размер файла в КБ	MAX_FILE_SIZE	100000	Предел для размера каждого файла журнала
Максимальное число дней для архива	MAX_HISTORY_SIZE	7	Количество дней хранения файлов журнала в архиве
Общий размер в ГБ всех файлов журнала для сохранения	TOTAL_SIZE_CAP	10	Ограничение размера всех файлов журнала в архиве

Сравнение режима кластера и режима одиночного сервера

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

• В режиме prudent не разрешено сжатие файлов. Один экземпляр не может выполнять запись, когда другой выполняет сжатие.

• Свойство файла FileAppender должно быть пустым. В большинстве операционных систем не разрешается переименовывать файл, пока он открыт другим процессом.

В следующем примере RollingFileAppender сконфигурирован с SizeAndTimeBasedRollingPolicy в режиме кластера:

<appender name="CONFIGURATION" class="ch.qos.logback.core.rolling.RollingFileAppender">

<prudent>true</prudent>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>{LOG_PATH}/ConfigurationLog.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
<maxHistory>{MAX_HISTORY_SIZE}</maxHistory>
<totalSizeCap>{TOTAL_SIZE_CAP}</totalSizeCap>
<maxFileSize>{MAX_FILE_SIZE}</maxFileSize>
</rollingPolicy>
<encoder class="com.thingworx.logging.ThingWorxPatternLayoutEncoder">
<pattern>{CONFIGURATION_LAYOUT_PATTERN}</pattern>
</encoder>
</appender>

В режиме одиночного сервера активный файл журнала будет помещен в папку {ThingworxStorage}/logs, а свернутый файл будет находиться в папке {ThingworxStorage}/logs/archive.

В следующем примере RollingFileAppender сконфигурирован с SizeAndTimeBasedRollingPolicyв режиме одиночного сервера:

<appender name="APPLICATION" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>{LOG_PATH}/ApplicationLog.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<fileNamePattern>{LOG_PATH}/archives/ApplicationLog.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
<maxHistory>{MAX_HISTORY_SIZE}</maxHistory>
<totalSizeCap>{TOTAL_SIZE_CAP}</totalSizeCap>
<maxFileSize>{MAX_FILE_SIZE}</maxFileSize>
</rollingPolicy>
<encoder class="com.thingworx.logging.ThingWorxPatternLayoutEncoder">
<pattern>{LAYOUT_PATTERN}</pattern>
</encoder>
</appender>

Было ли это полезно?