Рекомендации по администрированию 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 и dbterm поддерживают ограничение перечня используемых шифров при установлении соединения с управляемыми БД.

Для конфигурации ограничений используемых шифров укажите требуемые режимы в файле ./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)#

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

Ручная очистка истории хранилища метрик Kintsugi (DBCM)#

Рекомендуется периодически очищать устаревшие данные для экономии дискового пространства согласно требованиям регламента организации.

Пример команды для удаления данных из хранилища метрик старше 48 ч:

SELECT metrics.drop_chunks(format('%I.%I', hypertable_schema, hypertable_name)::regclass, INTERVAL '48h') FROM timescaledb_information.hypertables;

Для настройки глубины очистки задайте значение параметру INTERVAL в формате времени PostgreSQL.

Пример использования вышеописанной команды с использованием cron job для запуска процесса очистки БД метрик по расписанию (например, ежедневно в 12 часов):

0 12 * * * echo "SELECT metrics.drop_chunks(format('%I.%I', hypertable_schema, hypertable_name)::regclass, INTERVAL '48h') FROM timescaledb_information.hypertables;" | psql -h <host> -U <user> -d <database> >> /path/to/log/cron.log 2>&1

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

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

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

Рекомендации по работе 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.