Рекомендации по администрированию Kintsugi (DBCM)#

Выполнение задач администрирования требует использования специализированных инструментов контроля состояния системы. В состав дистрибутива входит конфигурация для отображения графиков данных о метриках, предназначенная для контроля системы средствами визуализации. Kintsugi интегрируется с системой Platform V Monitor (OPM): Журналирование (LOGA) с возможностью визуализации и хранения сообщений системы.

Настройка мониторинга и журналирования выполняется на стороне компонентов продукта Platform V Monitor (OPM): Журналирование (LOGA) и Объединенный мониторинг Unimon (MONA).

Ограничение SSL-режимов для подключения к управляемым БД#

Сервис поддерживает следующие режимы подключения к управляемым БД:

  • disable;

  • allow;

  • prefer;

  • require;

  • verify-ca;

  • verify-full.

По умолчанию разрешены все указанные режимы.

Чтобы указать разрешенные SSL-режимы для подключения к управляемым БД, настройте соответствующие параметры в файле ./helm/application/kintsugi/values.yaml.

Пример конфигурации:

managedDatabases:
  allowedSslModes:
    - "disable"
    - "allow"
    - "prefer"
    - "require"
    - "verify-ca"
    - "verify-full"

Данная конфигурация разрешает выполнение подключений к управляемым БД в режимах verify-ca и verify-full.

Ограничение используемых шифров при установлении соединения с управляемыми БД#

Сервисы collector и dbperf поддерживают возможность ограничения списка используемых шифров при соединении с управляемыми БД.

Чтобы ограничить используемые шифры, укажите необходимые значения в файле ./helm/application/kintsugi/values.yaml.

Пример конфигурации:

managedDatabases:
  cipherSuites:
    - "TLS_AES_128_GCM_SHA256"
    - "TLS_AES_256_GCM_SHA384"
    - "TLS_CHACHA20_POLY1305_SHA256"
    - "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"
    - "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA"
    - "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
    - "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
    - "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
    - "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
    - "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
    - "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
    - "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
    - "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256"

По умолчанию применяется стандартный набор шифров, заданный на уровне программной библиотеки.

Ограничение использования корневого сертификата для подключения к управляемым БД#

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

Чтобы активировать режим ограничения использования корневого сертификата, добавьте сертификат в файл ./helm/application/kintsugi/values.yaml.

Пример конфигурации:

secrets:
  managedDatabases:
    data:
      force_root_cert.secret: <СОДЕРЖИМОЕ СЕРТИФИКАТА>

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

Администрирование баз данных Kintsugi (DBCM)#

Резервное копирование баз данных Kintsugi (DBCM)#

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

Использование менеджеров пула соединений типа PgBouncer при работе с базами данных#

При добавлении объектов мониторинга используйте порт для прямого подключения к наблюдаемым БД (без использования менеджеров пула соединений типа PgBouncer и ему подобных).

Прямое подключение без использования пулов соединений требуется также при подключении к внутренним базам данных мониторинга и метаинформации Kintsugi (DBCM).

Рекомендации по работе Kintsugi (DBCM) с логами СУБД#

Kintsugi (DBCM) обрабатывает исключительно лог-файлы PostgreSQL, имена которых соответствуют установленным шаблонам имен.

Несоответствие этим шаблонам приводит к следующим проблемам:

  • игнорирование файлов при обработке;

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

  • усложнение автоматической сортировки логов по времени.

Имя лог-файла PostgreSQL должно иметь формат postgresql-%Y-%m-%d_%H%M%S.log, где %Y-%m-%d_%H%M%S представляет собой временную метку формата «год-месяц-день_часыминутысекунды».

Примеры корректных имен:

  • postgresql-2025-10-25_153000.log;

  • postgresql-2025-09-30_084512.log.

Архивные файлы логов (форматы gzip и zip) должны соответствовать шаблонам:

  • postgresql-YYYY-MM-DD_HHMMSS.log.gz;

  • postgresql-YYYY-MM-DD_HHMMSS.log.zip.

Примеры допустимых архивов:

  • postgresql-2025-10-25_153000.log.gz;

  • postgresql-2025-09-30_084512.log.zip.