Перейти к основному содержимому

Системный журнал

Настройка системного журнала​

События системного журнала сохраняются в файл, путь к которому определяется в настройках компонента. Конфигурация системного журнала осуществляется через конфигурационные файлы, которые соответствуют каждому компоненту сервиса: /etc/pbr/<service-name>.yaml.

Внимание!

Для компонента Recovery Manager используется конфигурационный файл ~/.pbr/recovery-manager.yaml.

Пример конфигурационного файла /etc/pbr/agent-manager.yaml для компонента Agent Manager в части журналирования:

log:
  path: /var/log/pbr/agent-manager.log
  max_size: 200
  max_age: 14
  max_backups: 10
  use_local_time: false
  compress_backups: false
Параметры конфигурирования

Наименование

Описание

path

Путь к файлу, в который будут записываться логи

max_size

Максимальный размер лог-файла в мегабайтах. По умолчанию 100 МБ

max_age

Максимальный срок хранения лог-файла в днях

max_backups

Максимальное количество исторических логов, которое может храниться одновременно. Если выбрано 0, то количество файлов не ограничено

use_local_time

Параметр определяет, в каком формате будут записываться метки времени в имена файлов при ротации:

  • true – используется локальное системное время;
  • false (задано по умолчанию) – используется UTС-время.

compress_backups

Параметр определяет необходимость сжатия лог-файлов:

  • true – сжатие включено;
  • false – сжатие не используется
к сведению

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

Порядок удаления логов​

Удаление логов выполняется в два этапа:

  1. Сначала проверяется ограничение max_backups. Если количество исторических логов превышает заданное значение, самые старые файлы удаляются.
  2. Затем проверяется ограничение max_age. Удаляются логи, возраст которых превышает указанное количество дней.

Таким образом, оба параметра применяются независимо друг от друга:

  • лог-файл будет удален, если превышено значение max_backups, даже если не превышен срок его хранения max_age;
  • лог-файл также будет удален, если срок его хранения превышает max_age, даже если количество логов не превышает max_backups.
Пример удаления логов

log:
  path: /var/log/pbr/agent-manager.log
  max_size: 100
  max_age: 90
  max_backups: 10
  use_local_time: false
  compress_backups: false

  1. При достижении размера 100 МБ текущий лог ротируется и становится историческим логом.

  2. Допустим, после очередной ротации в каталоге находится 11 исторических логов:

    copywala.log.1
    copywala.log.2
    КОД ПРОПУЩЕН: <вывод логов с 3 по 10>
    copywala.log.11

  3. Сначала применяется правило max_backups: 10: так как количество исторических логов превышает 10, самый старый лог (copywala.log.11) будет удален, даже если ему меньше 90 дней.

  4. После этого применяется правило max_age: 90: если среди оставшихся логов есть файлы старше 90 дней, они также будут удалены, даже если общее количество логов не превышает max_backups.

Доступ к системному журналу​

Доступ к системному журналу имеет только администратор системы.

Основные события​

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

Для сообщений применимы следующие уровни логирования:

  • Error − записываются сообщения обо всех ситуациях или событиях в приложении, которые считаются ошибочными:

    • ошибки вызова внешних сервисов;
    • ошибки интеграционных вызовов;
    • ошибки, ведущие к падению одного из сервисов.

    Пример:

    2025-01-13 16:22:36.453 [1415876] ERR failed to handle request due to error err="failed to dispatch error: failed to commit task cancellation: failed to update task status: failed to connect to user=postgres database=postgres:\n\t[::1]:45432 (localhost): dial error: dial tcp [::1]:45432: connect: connection refused\n\t127.0.0.1:45432 (localhost): dial error: dial tcp 127.0.0.1:45432: connect: connection refused\n\t[::1]:45432 (localhost): dial error: dial tcp [::1]:45432: connect: connection refused\n\t127.0.0.1:45432 (localhost): dial error: dial tcp 127.0.0.1:45432: connect: connection refused" method=POST url=/api/task-manager/1/tasks/0194079b-5048-7dcf-9f05-c65c3fc55c3a:cancel

    Где 1415876 – идентификатор процесса в операционной системе.

  • Warning – предупреждения о некорректной работе сервиса.

    Пример:

    2025-01-13 16:20:35.866 [1415586] WRN REST API server is being configured without TLS configuration

    Где 1415586 – идентификатор процесса в операционной системе.

  • Info – информация о работе приложения и текущем состоянии сервисов.

    Пример:

    2025-12-19 17:18:46.144 [2315586] INF instance successfully entered online backup state
    2025-12-19 17:18:46.447 [2315586] INF requesting data directory path to perform backup
    2025-12-19 17:18:46.876 [2315586] INF successfully received data directory path data_directory=/pgdata/06/data

    Где 2315586 – идентификатор процесса в операционной системе.