pg_integrity_verifier

pg_integrity_verifier — это специализированный инструмент, предназначенный для мониторинга целостности баз данных PostgreSQL. Приложение предназначено для помощи администраторам СУБД или специалистам по безопасности в контроле целостности баз данных. Оно сохраняет записи состояний баз данных в указанной директории, а в случае каких-либо изменений в наблюдаемых базах данных создает снимок в формате sn_{database}_{datetime}.diff. Затем pg_integrity_verifier выполняет команду, указанную в run_command в основном файле конфигурации. В run_command указывается команда, скрипт или другое приложение, предназначенное для анализа изменений и принятия решений. Например, если зафиксировано изменение структуры какой-либо таблицы, может быть выполнена отправка уведомления ответственным специалистам. Как и куда будет отправлено уведомление должно определяться исключительно внешним приложением. Кроме уведомлений могут быть выполнены действия, модифицирующие структуру СУБД или ее конфигурации.

pg_integrity_verifier может быть запущен любым пользователем ОС Linux, имеющим полномочия на запуск исполняемого файла. Важно отметить, что единственное допустимое место подключения к базам данных для контроля целостности — это текущий хост, то есть pg_integrity_verifier должен быть запущен на одном хосте с наблюдаемой базой данных. Это необходимо, так как для контроля целостности файлов конфигурации PostgreSQL postgresql.conf и pg_hba.conf приложению необходим локальный доступ к ним. Проверка целостности может применяться к разным сущностям БД: пользователям, конфигурациям, таблицам, функциям, триггерам и так далее.

Параметры запуска

Список параметров запуска для pg_integrity_verifier:

Пример запуска:

./pg_integrity_verifier -l log4rs.yaml -c pg_integrity_verifier.yaml

Основной файл конфигурации

Конфигурация pg_integrity_verifier задается в параметре -c через основной файл конфигурации в формате yaml. Этот файл позволяет устанавливать различные параметры, определяющие взаимодействие приложения с наблюдаемыми базами данных.

Структура файла:

mode: "<режим работы: one_time или daemon>"
daemon_period: "<интервал в секундах для режима daemon>"
databases:
  - db_url: "postgres://<имя пользователя>:<пароль>@<адрес БД>:<порт>/<имя БД>"
    snapshot_directory: "<каталог для снимков БД>"
    observed_objs: [<список объектов БД для мониторинга>]
    run_command: "<команда или скрипт для выполнения при обнаружении изменения> -f DIFF_FILE"
  - ...

Где:

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

mode: "daemon"
daemon_period: "5"
databases:
  - db_url: "postgres://postgres:12345@localhost:5432/db1"
    snapshot_directory: "json1"
    observed_objs: ['config_file', 'pg_hba', 'pg_settings', 'pg_user', 'pg_proc', 'pg_trigger', 'pg_roles']
    run_command: "tests/run_command.sh -f DIFF_FILE"
  - db_url: "postgres://postgres:54321@localhost:5432/db2"
    snapshot_directory: "json2"
    observed_objs: ['config_file', 'pg_hba', 'pg_settings', 'pg_user', 'pg_proc', 'pg_trigger', 'pg_roles']
    run_command: "tests/run_command.sh -f DIFF_FILE"

Файл конфигурации для ведения журнала

Конфигурация ведения журнала событий и сообщений приложения задается в параметре -l также через файл в формате yaml.

Структура файла:

refresh_rate: "<интервал обновления конфигурации в секундах> seconds"
appenders:
  <название компонента>:
    kind: <тип компонента: console, file, rolling_file, udp или tcp>
    encoder:
      pattern: "<шаблон вывода или записи>"
    path: "<путь к файлу лога>" # Только для типов компонентов file и rolling_file
    policy: # Только для типа компонентов rolling_file
      trigger:
        kind: <тип условия: size, time или compound>
        limit: <размера файла в байтах> # Только для типа условия size
        schedule: <расписание в формате cron с расширением для секунд> # Только для типа условия time
      roller:
        kind: <тип механизма ротации: fixed_window, delete или compound>
        base: <начальный индекс> # Только для типа механизма ротации fixed_window
        count: <количество файлов> # Только для типа механизма ротации fixed_window
        pattern: "<шаблон имени для ротации>"
    endpoint: "<адрес>:<порт>" # Только для типов компонентов udp и tcp
    reconnect:  # Только для типа компонентов tcp
      strategy: <стратегия переподключения: immediate или fixed>
      delay_ms: <задержка перед попыткой переподключения в миллисекундах> # Только для стратегии fixed
root:
  level: <минимальный уровень логирования: trace, debug, info, warn, error>
  appenders:
    - <название компонента 1>
    - <название компонента 2>
    ...

Где:

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

refresh_rate: 5 seconds
appenders:
  stdout:
    kind: console
    encoder:
      pattern: "{d(%Y-%m-%d %H:%M:%S)} - {m}{n}"
  my_file_logger:
    kind: rolling_file
    path: "logs/pg_integrity.log"
    encoder:
      pattern: "{d(%Y-%m-%d %H:%M:%S)} - {m}{n}"
    policy:
      trigger:
        kind: size
        limit: 104857600
      roller:
        kind: fixed_window
        base: 1
        count: 10
        pattern: "logs/pg_integrity_{}.log"
root:
  level: info
  appenders:
    - stdout
    - my_file_logger

Пример использования

Таким образом, для информирования администраторов СУБД можно использовать скрипты, которые будут вызваны приложением pg_integrity_verifier при фиксировании изменений в наблюдаемой БД. В рассмотренном примере alert_example.sh принимает через аргумент -f файл, содержащий перечень изменений, и отображает его содержимое. Для реального применения содержимое входящего файла должно быть интерпретировано, и на основе изменений должна быть вызвана внешняя система, выполняющая функции уведомлений, например, отправка e-mail или оповещение в мессенджере.