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

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

Просмотр сообщений системного журнала Kintsugi (DBCM) осуществляется с помощью сервиса Журналирование (LOGA) (далее – компонент Журналирование), если он доступен в инфраструктуре. В случае его отсутствия просмотр сообщений системного журнала выполняется с помощью сервиса сбора записей о событиях, совместимого с Fluent Bit, например: Elasticsearch.

Настройка интеграции с системным журналом описана в документе «Руководство по установке» раздел «Установка компонента Kintsugi (DBCM)».

Все сообщения системного журнала имеют формат человекочитаемого сообщения.

Предусмотрены следующие уровни журналирования:

  1. ERROR – записываются сообщения обо всех ситуациях или событиях в приложении, которые считаются ошибочными:

    • ошибки вызова внешних сервисов;

    • ошибки интеграционных вызовов;

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

  2. WARN – предупреждения о некорректной работе сервиса;

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

  4. DEBUG – подробности о работе приложения, позволяющие восстановить последовательность выполнения операций при обслуживании запросов и вызовах внешних систем.

Примечание

Не рекомендуется использовать уровень логирования DEBUG в промышленной эксплуатации.

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

Для просмотра логов Kintsugi (DBCM) используйте Elasticsearch или Apache Kafka.

Логи сервиса KgAgent компонента Kintsugi agent (DBDA) можно увидеть в системном журнале, так как он устанавливается на хосте.

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

Основные события сервисов, разработанных на языке Python#

В Platform V Kintsugi (DBM) следующие сервисы разработаны на языке Python: frontend, backend, curator, kmetrics, audit proxy, piface, inform и alerting.

События данных сервисов регистрируются в формате: <Дата и время> | <Уровень логирования> | <Описание ошибки>.

Ниже приведены некоторые события логирования.

Уровень

Текст/шаблон сообщения

Перевод

ERROR

app.routers.connections:get_database_list_impl:54 - an error occurred while trying to connect to the database to perform introspection action: [Error 104] Connection reset by peer

Маршрутизация подключений: попытка подключения к базе данных для выполнения действия интроспекции завершилась неудачно: [Ошибка Error 104] Разрыв соединения по инициативе клиента

DEBUG

app.routers.probes:readiness:27 - readiness: positive response given

Проверка готовности: положительный ответ дан

DEBUG

app.routers.probes:liveness:33 - liveness: positive response given

Проверка активности: положительный ответ дан

WARN

inform.metrics.polling_modules.poll_queue:_is_first_element_ready:64 - poll_queue: (asset_id=307957a1-a7dd-15f7c13b63cc): early to poll. poll will be executed in 99.423 second(s)

Очередь опроса метрик: элемент очереди (Asset ID=307957a1-a7dd-15f7c13b63cc): рано для опроса. Опрос будет выполнен через 99.423 секунды

WARN

inform.metrics.polling_modules.poll_queue:_is_first_element_ready:64 - poll_queue: (asset_id=307957a1-a7dd-15f7c13b63cc): early to poll. poll will be executed in 75.986 second(s)

Очередь опроса метрик: элемент очереди (Asset ID=307957a1-a7dd-15f7c13b63cc): рано для опроса. Опрос будет выполнен через 75.986 секунды

INFO

logging:callHandlers:1661 - 127.X.X.X:Y - "GET /metrics HTTP/1.1" 200

Информация о вызове обработчиков логирования: [IP-адрес]:[порт] - «GET /metrics HTTP/1.1» 200

Основные события сервисов, разработанных на языке Golang#

В Platform V Kintsugi (DBM) следующие сервисы разработаны на языке Golang: AgentWay, collector, dbperf, mcwatch, scheduler и KgAgent.

События данных сервисов регистрируются в формате: <Уровень ошибки> : <Дата и время> <Код файла и номер строки>: <Описание ошибки>.

Ниже приведены некоторые события логирования.

Уровень

Текст/шаблон сообщения

Перевод

ERROR

ERROR: 2025/07/01 12:53:38.764808 dbconnector.go:447: Connector 73d09875-896c-cda644a394bd ( 10.X.X.X:Y /postgres ):: fail to connect: failed to connect to host=10.X.X.X user=postgres database=postgres: tls error (read tcp 192.X.X.X:Y->10.X.X.X:Y : read: connection reset by peer)

Не удалось подключиться к хосту = 10.X.X.X пользователю = postgres базе данных = postgres: ошибка TLS (разрыв соединения по инициативе клиента)

ERROR

ERROR: 2025/07/01 12:53:38.764924 dbconnector.go:177: Connector 73d09875-896c-cda644a394bd  refreshed connections has inconsistent version info: no version info found

Обновление соединений: версия обновленных соединений не совпадает с версией, которую предполагалось использовать. Версия не найдена

DEBUG

DEBUG: 2025/07/01 13:10:23.521653 scraper.go:193: processing with promql map len = 39

Обработка с помощью promql карты длины = 39

DEBUG

DEBUG: 2025/07/01 13:10:23.521968 pipeline.go:32: Pipeline:  Received duration = 0s

Пайплайн: Получено продолжительность = 0s

WARN

WARN: 2025/07/01 12:53:48.760857 scraper.go:278: Scraper 73d09875-896c-cda644a394bd:  metrics can not will be collected, 0 metrics sources available

Метрики не могут быть собраны, доступно 0 источников метрик

WARN

WARN: 2025/07/01 12:53:48.792487 dbconnector.go:374: Connector 01e28db3-3149-9ae8a169f7cf 10.X.X.X:Y/postgres: failed sql query = SELECT t2.rolname, t3.datname, (sum(t1.shared_blks_dirtied + t1.local_blks_dirtied)) * current_setting('block_size')::bigint AS dirty FROM pg_stat_statements t1 JOIN pg_roles t2 ON t1.userid = t2.oid JOIN pg_database t3 ON t1.dbid = t3.oid WHERE datname NOT IN ('template0', 'template1') GROUP BY rolname, datname ORDER BY dirty DESC LIMIT 25

Ошибка SQL-запроса

INFO

INFO: 2025/07/01 12:53:28.805985 dbconnector.go:298: Connector 01e28db3-3149-9ae8a169f7cf ( 10.X.X.X:Y/postgres ): 19 sources processed, query: (19 executed, 0 skipped, 3 failed), metrics: (36 created, 0 failed)

19 источников обработано, запрос: (19 выполнено, 0 пропущено, 3 провал), метрики: (36 создано, 0 провалено)

INFO

INFO: 2025/07/01 12:53:28.806204 scraper.go:257: Pipeline:  maintenance has been finished, actual storage size, len = 108, cap = 1700

Пайплайн: техническое обслуживание завершилось, фактический размер хранилища, длина = 108, емкость = 1700

Описание событий «Error», приводящих к падению Kintsugi (DBCM)#

В целях ознакомления приведены сообщения, приводящие к падению Kintsugi (DBCM).

Сообщение

Сервис, сгенерировавший ошибку

Причина возникновения

{{название сервиса}} error initialize configuration from {{название файла конфигурации}}: {{ошибка}}

collector *

Ошибка инициализации конфигурации сервиса

{{название сервиса}} error initialize logs from configuration {{название файла конфигурации}}: {{ошибка}}

collector *

Ошибка инициализации логов сервиса

error read queries from file {{название файла}}: {{ошибка}}

collector

Ошибка чтения запросов метрик из файла

error initializing queries from file {{название файла}}: {{ошибка}}

collector

Ошибка инициализации запросов метрик из файла

cannot build connection configuration: {{ошибка}}

collector

Ошибка при попытке сформировать параметры подключения к наблюдаемой БД

{{информация о подключении}}: nil pointer expected

collector

Ошибка формирования подключения к БД

{{информация о подключении}} bad connection information: {{подключение}}

collector

Ошибка в сформированной строке подключения к БД

Примечание

* – применимо также к сервису audit proxy.

Описание событий типа «Error», приводящих к падению Kintsugi agent (DBDA)#

Таблица содержит примеры сообщений, приводящих к падению Kintsugi agent.

Сообщение

Сервис, сгенерировавший ошибку

Причина возникновения

{{название сервиса}} error initialize configuration from {{название файла конфигурации}}: {{ошибка}}

KgAgent

Ошибка инициализации конфигурации сервиса

{{название сервиса}} error initialize logs from configuration {{название файла конфигурации}}: {{ошибка}}

KgAgent

Ошибка инициализации логов сервиса

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

Настройка уровня логирования выполняется на этапе установки компонента Kintsugi (DBCM) и описана в документе «Руководство по установке» раздел «Установка веб-интерфейса компонента Kintsugi (DBCM)» пункт «Конфигурация Helm-чарта Kintsugi».

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

  1. Отредактируйте файл values.yaml Helm-чарта Kintsugi (DBCM) и установите параметр logLevel на нужный уровень.

  2. Повторно разверните Helm-чарт с обновленными значениями:

    helm upgrade <release-name> <chart-name> -f values.yaml -n <namespace>

  3. Убедитесь, что в системном журнале отображаются сообщения только указанного уровня и выше (иерархия: ERROR < WARN < INFO < DEBUG).

Примечание

Использование уровня логирования DEBUG увеличивает объем записываемых событий и может отрицательно сказаться на производительности системы. Используйте уровень DEBUG исключительно для диагностики неисправностей.

Настройка вывода логов Kintsugi agent (DBDA)#

Параметры вывода логов Kintsugi agent (DBDA) задаются в блоке logging.output конфигурационного файла /etc/kgagent/config.yaml и описаны в документе «Руководство по установке» раздел «Установка компонента Kintsugi agent (DBDA) (опциональный)» пункт «Настройка интеграции Kintsugi agent (DBDA) с системой Kintsugi (DBCM)».

Параметр logging.output.type определяет тип вывода логов и принимает одно из следующих значений:

  • "stdout" — вывод логов в стандартный поток вывода (журнал systemd).

  • "file" — вывод логов в файл.

Примечание

При выборе значения "file" необходимо указать все параметры ротации: log_file, log_path, log_rotate_limit_mb, log_rotate_interval_days, log_rotate_max_backups.

Пример конфигурации для вывода логов в файл:

logging:
  log_level: info
  fluent_config:
    inuse: false
  output:
    type: "file"
    log_file: "kgagent.log"
    log_path: "/bin/kgagent/logs"
    log_rotate_limit_mb: 100
    log_rotate_interval_days: 30
    log_rotate_max_backups: 200
    log_rotate_compress: true

Чтобы применить изменения, перезапустите сервис KgAgent:

sudo systemctl restart kgagent

Проверить создание лог-файла в указанной директории:

ls -la /bin/kgagent/logs/