F.70. proxima — комбинация прокси и пула соединений
Пред. НаверхПриложение F. Дополнительно поставляемые модули и расширения, поставляемые в postgrespro-ent-17-contribНачало След.

F.70. proxima — комбинация прокси и пула соединений #

F.70.1. Обзор
F.70.2. Особенности и ограничения
F.70.3. Управление расширением proxima
F.70.4. Устранение неполадок
F.70.5. Параметры конфигурации
F.70.6. Метрики мониторинга

proxima — это расширение Postgres Pro Enterprise, объединяющее функциональность прокси-сервера и пула соединений.

F.70.1. Обзор #

Расширение proxima можно использовать на одноузловом сервере Postgres Pro Enterprise, в стандартном кластере Postgres Pro Enterprise конструкции ведущий-ведомый, а также в BiHA-кластере. Расширение предоставляет следующие возможности:

  • Прокси-сервер: proxima становится единой точкой клиентских подключений и перенаправляет запросы на ведущий сервер или лидеру BiHA-кластера.

  • Распределение нагрузки: proxima может распределять читающую нагрузку между репликами в кластере.

  • Пул соединений: proxima управляет обслуживающими процессами, чтобы сократить потребление системных ресурсов и предотвратить снижение производительности.

  • Поддержка SSL: расширение proxima можно настроить для работы с SSL-соединениями.

  • Мониторинг: при использовании расширения proxima с решением BiHA доступно множество метрик для отслеживания состояния proxima.

  • Динамический выделенный сеанс: proxima поддерживает сеанс между клиентом и обслуживающим процессом на протяжении всего времени существования клиентского подключения.

F.70.1.1. Аутентификация #

Расширение proxima использует правила аутентификации, указанные в файле pg_hba.conf. Поддерживаются следующие методы аутентификации:

F.70.1.2. Работа в BiHA-кластере #

В расширении proxima есть специальный режим работы для BiHA-кластера. При установке в BiHA-кластере proxima автоматически получает от biha все необходимые конфигурационные параметры, например:

  • количество узлов кластера

  • идентификаторы, адреса и порты узлов

  • роли узлов (лидер или последователь)

Расширение proxima не работает на узле-рефери.

Вы можете установить расширение proxima в существующий BiHA-кластер или включить расширение при подготовке кластера с нуля.

При использовании в BiHA-кластере proxima регистрирует ряд функций-обработчиков для получения информации о событиях в кластере. Например, если лидер кластера изменяется, proxima получает уведомление об этом событии и автоматически перенаправляет трафик на нового лидера.

F.70.1.3. Распределение нагрузки #

Расширение proxima предоставляет следующие порты для обработки клиентских сеансов:

  • Порт Proxy-to-Leader (P2L) перенаправляет всю нагрузку на ведущий узел (лидер). Номер порта по умолчанию — 4545, его можно изменить с помощью параметра proxima.port.

  • Порт Proxy-to-Follower (P2F) распределяет читающую нагрузку между репликами в кластере. Номер порта по умолчанию — 4547, его можно изменить с помощью параметра proxima.p2f_port.

    Примечание

    В BiHA-кластере читающая нагрузка, направленная на порт P2F, может также перенаправляться на лидер в состоянии LEADER_RO. За подробной информацией о состояниях узлов BiHA-кластера обратитесь к таблице biha.status_v.

Чтобы распределить нагрузку между узлами кластера, настройте клиентское приложение таким образом, чтобы пишущая нагрузка направлялась на порт P2L, а читающая — на порт P2F. За подробной информацией обратитесь к разделу Настройка распределения нагрузки.

Важно

Расширение proxima прикрепляет клиентский сеанс к определённому узлу кластера и таким образом обеспечивает выполнение всех транзакций в рамках этого сеанса на одном узле. Если узел выйдет из строя во время сеанса, клиентское соединение будет разорвано.

F.70.1.4. Динамический выделенный сеанс #

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

Примечание

Если вы используете расширения, которые хранят своё состояние в рамках сеанса, вам нужно вручную включить принудительный динамический выделенный сеанс. За дополнительной информацией обратитесь к Управление динамическими выделенными сеансами вручную.

Расширение proxima автоматически устанавливает динамический выделенный сеанс, если запрос содержит следующие объекты или функции SQL:

Сеанс остаётся выделенным, пока упомянутые выше объекты не будут удалены.

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

F.70.1.5. Мониторинг #

Расширение proxima предоставляет функциональность мониторинга для отслеживания состояния proxima с помощью ряда метрик. Сейчас мониторинг доступен для BiHA-кластеров с включённым расширением proxima.

Расширение proxima регистрирует схему proxima в базе данных biha_db, где создаёт специальные представления для запросов метрик. За подробной информацией о просмотре метрик и примером SQL-запроса обратитесь к Просмотр метрик мониторинга.

F.70.1.5.1. Передача метрик между узлами кластера #

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

F.70.1.5.2. Особенности запросов через for порты P2L и P2F #

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

  • При подключении через порт P2L метрики будут получены с лидера кластера.

  • При подключении к порту P2F proxima может распределить идущие подряд запросы между разными узлами. Так как доставка метрик происходит с задержкой, в некоторых случаях идущие подряд запросы могут показывать уменьшение интегральных счётчиков.

За подробной информацией о портах P2L и P2F обратитесь к Распределение нагрузки.

Чтобы обеспечить монотонность роста счётчиков, при обработке результата всегда берите максимальное значение между текущими и ранее полученными значениями метрик.

F.70.2. Особенности и ограничения #

В этом разделе перечислены особенности и ограничения, которые необходимо учитывать при использовании proxima.

  • Расширение proxima не управляет репликацией между узлами кластера. Для обеспечения согласованности данных на всех узлах используйте Встроенная отказоустойчивость (BiHA) или настройте репликацию вручную.

  • IPv6 не поддерживается.

  • Процессорные архитектуры Эльбрус, ppc64le и s390x не поддерживаются.

  • При использовании в BiHA-кластере proxima регистрирует ряд функций-обработчиков для получения информации о событиях в кластере. Функции-обработчики размещаются в таблице biha.callbacks базы данных biha_db на узлах BiHA-кластера. Не удаляйте функции-обработчики, так как в этом случае proxima не сможет реагировать на события в кластере.

  • При использовании в стандартном кластере конструкции ведущий-ведомый или в BiHA-кластере сразу после запуска расширение proxima может записывать в журнал сообщения об ошибках подключения или синхронизации. Это нормальное поведение, потому что узлы запускаются в разное время. Сообщения об ошибках прекратятся вскоре после запуска.

  • На текущий момент в proxima отсутствует механизм автоматической установки динамических выделенных сеансов при использовании расширений, которые хранят своё состояние в рамках сеанса. В таких случаях необходимо вручную включить принудительный динамический выделенный сеанс.

  • Чтобы пул соединений обрабатывал большое число клиентских подключений, установите предел количества открытых файлов, превышающий число планируемых подключений:

    sudo echo '* soft nofile {значение}' >> /etc/security/limits.conf
sudo echo '* hard nofile {значение}' >> /etc/security/limits.conf
ulimit -n {значение}

    Например, если планируемое число клиентских подключений — 10000, в {значении} укажите 11000.

F.70.3. Управление расширением proxima #

В этом разделе описана установка, настройка и использование proxima.

F.70.3.1. Установка и настройка #

Расширение proxima — это встроенное расширение Postgres Pro Enterprise. Чтобы включить и настроить proxima, выполните следующие действия:

  1. Остановите сервер Postgres Pro Enterprise с помощью pg_ctl:

    pg_ctl stop -D каталог_PGDATA

  2. Добавьте proxima в shared_preload_libraries в файле postgresql.conf:

    shared_preload_libraries = 'proxima'

    При использовании многоузлового кластера повторите этот шаг для каждого узла.

  3. В зависимости от конфигурации Postgres Pro Enterprise задайте параметры конфигурации proxima в postgresql.conf:

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

      proxima.cluster_mode = 'standalone'

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

      proxima.cluster_mode = 'guc'
proxima.cluster_config = 'id_узла0,адрес_узла0,порт_узла0,роль_узла0;id_узла1,адрес_узла1,порт_узла1,роль_узла1;'
proxima.cluster_node_id = id_узла

      Например:

      proxima.cluster_mode = 'guc'
proxima.cluster_config = '0,192.168.0.57,4590,P;1,192.168.0.77,4590,S;'
proxima.cluster_node_id = 0

      Убедитесь, что на всех узлах указаны одинаковые значения proxima.cluster_config, а значения proxima.cluster_node_id уникальны для каждого узла.

    • Для BiHA-кластера задайте следующий параметр конфигурации:

      proxima.cluster_mode = 'biha'

      При использовании proxima с biha не требуется указывать параметры конфигурации кластера, так как proxima получает эту информацию напрямую от biha.

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

    Если никакие параметры не заданы, proxima использует значения по умолчанию. За подробной информацией о конфигурационных параметрах и их значениях по умолчанию обратитесь к Подразделу F.70.5.

  5. Запустите узел с помощью pg_ctl:

    pg_ctl start -D каталог_PGDATA

F.70.3.2. Конфигурирование SSL #

F.70.3.2.1. Включение SSL #

SSL можно включить как для входящих клиентских подключений, так и для внутреннего взаимодействия между узлами кластера.

  1. Остановите узлы кластера с помощью pg_ctl.

  2. Сгенерируйте сертификат и закрытый ключ с помощью утилиты OpenSSL:

    openssl req -x509 -newkey rsa:4096 -keyout путь_к_ключу -out путь_к_сертификату -sha256 -days срок_действия -nodes -subj "/CN=домен_сертификата"

    Например:

    openssl req -x509 -newkey rsa:4096 -keyout ./key.pem -out ./cert.pem -sha256 -days 256 -nodes -subj "/CN=localhost"

  3. В postgresql.conf укажите пути к сгенерированному сертификату и закрытому ключу:

    proxima.ssl_key = '/путь/к/key.pem'
proxima.ssl_cert = '/путь/к/cert.pem'

    Если параметры proxima.ssl_cert и proxima.ssl_key не заданы, proxima использует сертификат и ключ, настроенные для Postgres Pro в ssl_cert_file и ssl_key_file.

  4. Задайте следующие параметры конфигурации:

    • Чтобы включить SSL для входящих подключений, установите для параметра proxima.ssl_enabled значение on:

      proxima.ssl_enabled = on

    • Чтобы включить SSL для взаимодействия между узлами кластера, установите для параметра proxima.p2p_ssl_enabled значение on:

      proxima.p2p_ssl_enabled = on

  5. Запустите узлы с помощью pg_ctl.

Все клиентские подключения к порту proxima или внутренние подключения между узлами кластера теперь защищены SSL.

F.70.3.2.2. Включение SSL-аутентификации для внутренних подключений #

Настройте SSL-аутентификацию для внутренних подключений между узлами кластера. В этой процедуре описана настройка SSL-аутентификации для кластера из двух узлов.

  1. Остановите узлы кластера с помощью pg_ctl.

  2. Создайте две пары публичных сертификатов и закрытых ключей с помощью утилиты OpenSSL:

    openssl req -x509 -newkey rsa:4096 -keyout путь_к_ключу -out путь_к_сертификату -sha256 -days срок_действия -nodes -subj "/CN=домен_сертификата"

    Например:

    openssl req -x509 -newkey rsa:4096 -keyout ./key1.pem -out ./cert1.pem -sha256 -days 256 -nodes -subj "/CN=localhost"

    и

    openssl req -x509 -newkey rsa:4096 -keyout ./key2.pem -out ./cert2.pem -sha256 -days 256 -nodes -subj "/CN=localhost"

  3. Создайте каталог и переместите в него сгенерированные сертификаты.

  4. Выполните следующую команду:

    openssl rehash путь_к_каталогу_с_сертификатами

  5. Задайте параметры конфигурации proxima.p2p_auth_methods и proxima.ssl_trusted_certs_dir следующим образом:

    proxima.p2p_auth_methods = 'ssl'
proxima.ssl_trusted_certs_dir = путь_к_каталогу_с_сертификатами

  6. Запустите узлы с помощью pg_ctl.

  7. Проверьте журнал, чтобы убедиться, что SSL-аутентификация прошла успешно.

    Следующие записи в журнале свидетельствуют о том, что в качестве метода аутентификации используется SSL и что аутентификация прошла успешно:

    [auth]: using SSL authentication
[auth]: authentication success

F.70.3.3. Управление динамическими выделенными сеансами вручную #

Некоторые расширения хранят своё состояние в рамках сеанса, для чего требуется удерживать сеанс между клиентом и обслуживающим процессом. При использовании таких расширений необходимо вручную включать динамический выделенный сеанс при каждом подключении с помощью параметра proxima.force_dedicated.

Управлять принудительным динамическим выделенным сеансом можно следующим образом:

  • Чтобы включить принудительный динамический выделенный сеанс, выполните следующую команду:

    SET proxima.force_dedicated = true;

  • Чтобы отключить принудительный динамический выделенный сеанс, выполните следующую команду:

    SET proxima.force_dedicated = false;

  • Чтобы проверить, является ли текущий сеанс выделенным, используйте параметр proxima.is_dedicated:

    SHOW proxima.is_dedicated;

    Возвращённое значение t означает, что сеанс выделенный, в то время как f означает, что сеанс не выделенный.

F.70.3.4. Настройка распределения нагрузки #

Расширение proxima позволяет настроить распределение нагрузки между узлами кластера. В примере ниже вы настроите распределение нагрузки для кластера из трёх узлов с адресами 192.168.0.1, 192.168.0.2 и 192.168.0.3, используя порты proxima по умолчанию — 4545 (P2L) и 4547 (P2F).

  1. Настройте клиентское приложение таким образом, чтобы пишущая нагрузка направлялась на порт P2L , а читающая — на порт P2F.

    На стороне клиента можно использовать параметр target_session_attrs, чтобы указать тип узла, на котором клиент должен выполнять транзакции и запросы при подключении к базе данных.

    Например, можно указать, что запросы должны выполняться только на репликах, и тогда в рамках текущего соединения клиент будет выполнять читающие запросы на порту P2F.

  2. (Необязательно) Укажите алгоритм распределения читающей нагрузки с помощью параметра proxima.load_balancer_algorithm.

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

    192.168.0.1:4545
192.168.0.1:4547
192.168.0.2:4545
192.168.0.2:4547
192.168.0.3:4545
192.168.0.3:4547

    Если вы используете libpq, обратитесь к Подразделу 35.1.1.3, чтобы узнать требования и синтаксис для указания множества адресов в строке подключения.

В результате при подключении к порту 4545 (P2L) пишущая нагрузка будет перенаправлена на ведущий узел (лидер). При подключении к порту 4547 (P2F) читающая нагрузка будет перенаправлена на одну из реплик в соответствии с выбранным алгоритмом.

F.70.3.5. Просмотр метрик мониторинга #

Просматривать метрики мониторинга в BiHA-кластере можно с помощью стандартных SQL-запросов к представлениям метрик:

  • Чтобы просмотреть все метрики кластера:

    SELECT * FROM proxima.proxima_metrics;

  • Чтобы просмотреть все метрики определённого узла:

    SELECT * FROM proxima.proxima_metrics WHERE node_id = идентификатор_узла;

  • Чтобы просмотреть метрики определённого класса, выполните запрос к представлению соответствующего класса. Например:

    SELECT * FROM proxima.proxima_metrics_client;

За подробной информацией о возможностях мониторинга обратитесь к Мониторинг.

За подробной информацией о доступных метриках обратитесь к Метрики мониторинга.

Ниже приведён пример запроса на просмотр всех метрик узла с идентификатором 0, а также результат запроса (обрезан, так как метрик очень много):

postgres=# SELECT * FROM proxima.proxima_metrics WHERE node_id = 0;
                  name                    |    class     | node_id |        value
-------------------------------------------+--------------+---------+----------------------
thread.1.active_time_ns                   | thread-load  |       0 |          12590006201
thread.1.purged_coroutines                | thread-load  |       0 |                    6
thread.1.transferred_coroutines_accepted  | thread-load  |       0 |                    2
thread.1.wakeup_requests_accepted         | thread-load  |       0 |                    0
thread.1.futex_wakeup_requests_accepted   | thread-load  |       0 |                22752
thread.1.active_coroutines_called         | thread-load  |       0 |                72905
thread.1.evrun_once                       | thread-load  |       0 |                38456
thread.1.evrun_nowait                     | thread-load  |       0 |                 8700
thread.1.scheduler.coroctx_in_use         | thread-load  |       0 |                   19
thread.1.scheduler.coroctx_cached         | thread-load  |       0 |                    6
thread.1.scheduler.cs_active              | thread-load  |       0 |                    1
thread.1.scheduler.cs_inactive            | thread-load  |       0 |                    1
thread.1.scheduler.cs_waiting_futex       | thread-load  |       0 |                    5
thread.1.scheduler.cs_wakeup_futex        | thread-load  |       0 |                    0
thread.1.scheduler.cs_waiting_io          | thread-load  |       0 |                   12
memory.lgist-0                            | memory       |       0 |                    0
memory.lgist-1                            | memory       |       0 |                    8
memory.lgist-2                            | memory       |       0 |                   15
memory.lgist-3                            | memory       |       0 |                  162
memory.lgist-4                            | memory       |       0 |                  737
memory.lgist-5                            | memory       |       0 |                 1490
memory.lgist-6                            | memory       |       0 |                  174
memory.lgist-7                            | memory       |       0 |                  295
memory.lgist-8                            | memory       |       0 |                   70
memory.lgist-9                            | memory       |       0 |                   32
memory.lgist-10                           | memory       |       0 |                   20
memory.lgist-11                           | memory       |       0 |                    9
memory.lgist-12                           | memory       |       0 |                    1
memory.lgist-13                           | memory       |       0 |                   71
memory.lgist-14                           | memory       |       0 |                   61
memory.lgist-15                           | memory       |       0 |                    0
memory.lgist-16                           | memory       |       0 |                    6
memory.lgist-17                           | memory       |       0 |                    1
memory.lgist-18                           | memory       |       0 |                    0
memory.lgist-19                           | memory       |       0 |                    0
memory.lgist-20                           | memory       |       0 |                    0
memory.lgist-21                           | memory       |       0 |                    0
memory.lgist-22                           | memory       |       0 |                    1
memory.lgist-23                           | memory       |       0 |                    0
memory.lgist-24                           | memory       |       0 |                    0
memory.usage                              | memory       |       0 |              6581078
memory.traffic                            | memory       |       0 |              7983836
client.lfe.now_connected                  | client       |       0 |                    1
client.lfe.accepted                       | client       |       0 |                    1
client.lfe.rejected                       | client       |       0 |                    0
client.lfe.disconnected                   | client       |       0 |                    0
client.lfe.auth_password                  | client       |       0 |                    0
client.lfe.auth_md5                       | client       |       0 |                    0
client.lfe.auth_scram_sha256              | client       |       0 |                    0
client.lfe.auth_trust                     | client       |       0 |                    1
client.lfe.auth_tls_accepted              | client       |       0 |                    0
client.lfe.auth_tls_rejected              | client       |       0 |                    0
client.rfe.now_connected                  | client       |       0 |                    0
client.rfe.connected                      | client       |       0 |                    0
client.rfe.disconnected                   | client       |       0 |                    0
client.lbe.enter_dedicated                | client       |       0 |                    0

F.70.3.6. Отключение и включение расширения proxima #

Расширение proxima можно временно отключить и затем вновь включить с помощью параметра конфигурации proxima.enabled:

  1. В файле postgresql.conf установите параметр proxima.enabled с необходимым значением:

    • Чтобы отключить proxima, установите параметр proxima.enabled со значением off:

      proxima.enabled = off

    • Чтобы включить proxima, установите параметр proxima.enabled со значением on:

      proxima.enabled = on

  2. Отправьте сигнал SIGHUP процессу proxima:

    kill -SIGHUP proxima_pid

    Здесь proxima_pid — ID процесса proxima.

F.70.3.7. Удаление proxima #

Чтобы отключить использование proxima:

  1. На всех узлах кластера удалите расширение из shared_preload_libraries в файле postgresql.conf.

  2. Перезапустите узлы с помощью команды pg_ctl.

F.70.4. Устранение неполадок #

В этом разделе содержится информация о типичных неполадках, с которыми можно столкнуться при использовании proxima, и способах их устранения.

F.70.4.1. База данных или пользователь не найдены #

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

  1. Убедитесь, что между узлами настроена репликация с помощью стандартного механизма репликации или с помощью BiHA.

  2. Если репликация настроена и работает, подождите некоторое время, так как данные могли ещё не дойти до реплики.

F.70.4.2. Не удалось подключиться к proxima #

Если не удаётся подключиться к proxima, выполните следующие действия:

  1. Убедитесь, что для подключения используется порт proxima.port.

  2. Убедитесь, что файл pg_hba.conf настроен корректно.

F.70.4.3. Сообщение в журнале: connection cannot be established #

Если вы видите в журнале это сообщение от proxima, выполните следующие действия:

  1. Убедитесь, что все узлы включены и нет проблем с сетью.

  2. Если вы используете режим работы кластера guc, убедитесь, что значения proxima.cluster_node_id настроены верно и совпадают с ID, указанными в proxima.cluster_config.

F.70.4.4. Сообщение в журнале: failed to create cluster manager #

Если вы используете режим работы кластера guc , убедитесь, что proxima.cluster_config настроен корректно:

  • указаны все необходимые значения

  • набор значений для каждого узла оканчивается точкой с запятой (;)

F.70.4.5. Сообщение в журнале: postgres: cannot accept new connection, error: Too many open files #

Увеличьте максимальное число открытых файлов с помощью команды ulimit -S -n.

F.70.5. Параметры конфигурации #

F.70.5.1. Общие параметры #

proxima.address (text) #

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

proxima.enabled (boolean) #

Временно включает и отключает расширение proxima. Доступны следующие значения:

  • off: временно останавливает расширение proxima.

  • on: запускает расширение proxima после временной остановки.

proxima.force_dedicated (boolean) #

Включает и отключает принудительные динамические выделенные сеансы. Доступны следующие значения:

  • true: включает принудительный динамический выделенный сеанс.

  • false: отключает принудительный динамический выделенный сеанс.

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

proxima.is_dedicated (boolean) #

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

  • t: сеанс выделенный.

  • f: сеанс не выделенный.

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

proxima.load_balancer_algorithm (text) #

Определяет алгоритм для распределения читающей нагрузки между репликами в кластере. Поддерживаются следующие значения:

  • round-robin: нагрузка перенаправляется на каждую реплику по очереди.

  • random: нагрузка перенаправляется на случайную реплику.

Значение по умолчанию — round-robin.

proxima.port (integer) #

Указывает порт Proxy-to-Leader (P2L) — TCP-порт, на котором proxima принимает входящие клиентские подключения и перенаправляет все запросы на ведущий узел (лидер).

В BiHA-кластере запросы перенаправляются на только на лидер в состоянии LEADER_RW. За подробной информацией о состояниях узлов в BiHA-кластере обратитесь к таблице biha.status_v.

Диапазон допустимых значений: от 0 до 65535. Значение по умолчанию — 4545. Рекомендуется указать одинаковое значение для параметра proxima.port на всех узлах кластера.

proxima.p2f_port (integer) #

Указывает порт Proxy-to-Follower (P2F) — TCP-порт, на котором proxima принимает входящие клиентские подключения и распределяет читающую нагрузку между репликами в кластере.

В BiHA-кластере читающая нагрузка также может быть перенаправлена на лидер в состоянии LEADER_RO. За подробной информацией о состояниях узлов BiHA-кластера обратитесь к таблице biha.status_v.

Диапазон допустимых значений: от 0 до 65535. Значение по умолчанию — 4547.

proxima.p2p_auth_methods (text) #

Указывает метод аутентификации для внутреннего взаимодействия между узлами кластера. Поддерживаются следующие методы:

Значение по умолчанию — trust. Можно перечислить несколько методов через запятую, например:

proxima.p2p_auth_methods = 'trust,ssl'

Если перечислить несколько методов, они будут применяться следующим образом в порядке убывания приоритета: ssl, trust.

proxima.p2p_ssl_enabled (boolean) #

Включает или отключает SSL для внутреннего взаимодействия между узлами кластера. Значение по умолчанию — off.

proxima.ssl_enabled (boolean) #

Включает или выключает SSL для входящих клиентских подключений к proxima.port. Значение по умолчанию — off. Если включить SSL и не задать параметры proxima.ssl_key и proxima.ssl_cert, proxima будет использовать SSL-сертификат, настроенный для Postgres Pro.

proxima.ssl_cert (text) #

Указывает путь к сертификату, который будет использоваться для SSL-соединения через proxima.port. Если значение не указано, proxima использует сертификат, указанный в ssl_cert_file. Если параметр задан, вам также нужно указать значение для proxima.ssl_key.

proxima.ssl_key (text) #

Указывает путь к файлу закрытого ключа. Если параметр не задан, proxima использует ключ, указанный в ssl_key_file. Если параметр задан, вам также нужно указать значение для proxima.ssl_cert.

proxima.ssl_trusted_certs_dir (text) #

Указывает путь к каталогу с доверенными сертификатами при настройке SSL-аутентификации с помощью proxima.p2p_auth_methods.

proxima.log_level (enum) #

Указывает уровень детализации сообщений proxima. Возможные значения: error, warning, info, verbose, debug. Значение по умолчанию — info.

proxima.workers (integer) #

Указывает число потоков, запускаемых для обработки запросов обслуживающим процессом proxima. Диапазон допустимых значений: от 1 до 65535. Чем выше значение, тем больше запросов может быть обработано. Значение по умолчанию — 4.

F.70.5.2. Конфигурирование кластера #

proxima.cluster_mode (text) #

Устанавливает режим работы кластера. Возможные режимы:

  • standalone — режим для одноузловой базы данных Postgres Pro.

  • guc — режим для стандартного кластера Postgres Pro конструкции ведущий-ведомый. Конфигурация кластера определяется параметрами proxima.cluster_config и proxima.cluster_node_id.

  • biha — режим для BiHA-кластера. В этом режиме конфигурация кластера передаётся расширением biha.

Значение по умолчанию — standalone. Значение этого параметра должно быть одинаковым на всех узлах кластера.

proxima.cluster_config (text) #

Устанавливает конфигурацию кластера для режима работы кластера guc. Значение этого параметра должно быть одинаковым на всех узлах кластера. Параметры подключения и идентификации необходимо указать для каждого узла следующим образом:

'id_узла,адрес_узла,порт_узла,роль_узла'

где:

  • id_узла — это идентификатор узла, в качестве которого необходимо указать значение в диапазоне от 0 до 255. Идентификатор узла должен быть уникальным для каждого узла в кластере.

  • адрес_узла — это IP-адрес узла для внутреннего соединения между узлами кластера.

  • порт_узла — это порт узла для внутреннего соединения между узлами кластера. Этот порт должен отличаться от proxima.port.

  • роль_узла — это роль узла в кластере. Возможные значения P (Primary, ведущий) и S (Standby, ведомый).

Пример значения proxima.cluster_config для кластера, состоящего из трёх узлов:

'0,127.0.0.1,4090,P;1,127.0.0.1,4091,S;2,127.0.0.1,4092,S;'
proxima.cluster_node_id (integer) #

Указывает уникальный идентификатор узла для режима работы кластера guc. Этот параметр не должен изменяться после запуска и до остановки кластера. Идентификатор узла должен быть уникальным для каждого узла кластера. Значение можно указать в диапазоне от 0 до 255. Значение по умолчанию — 0.

Список идентификаторов узлов должен всегда начинаться с 0 и заканчиваться n-1, где n — общее число узлов. Например, для кластера из трёх узлов идентификаторы узлов должны быть 0, 1, 2.

F.70.5.3. Настройка локального пула обслуживающих процессов #

Следующие параметры устанавливают ограничения для пула локальных обслуживающих процессов — Postgres Pro, обрабатывающих клиентские запросы.

proxima.backend_pool_local_total_limit (integer) #

Устанавливает максимальное число обслуживающих процессов, которые могут быть созданы на узле. Диапазон допустимых значений: от 1 до MAX_BACKENDS. Значение по умолчанию — 100.

proxima.backend_pool_local_bucket_limit (integer) #

Устанавливает максимальное число обслуживающих процессов, которые могут быть созданы в рамках подключений, идентифицированных связкой user + database. Диапазон допустимых значений: от 1 до значения, указанного в proxima.backend_pool_local_total_limit. Значение по умолчанию — 100.

proxima.backend_pool_local_overdue_interval (float) #

Устанавливает время бездействия локального обслуживающего процесса в секундах. Если локальный обслуживающий процесс не используется клиентами дольше, чем установлено этим параметром, обслуживающий процесс будет остановлен. Диапазон допустимых значений: от 1.0 до 86400.0. Значение по умолчанию — 10.0.

F.70.5.4. Настройка пула удалённых обслуживающих процессов #

Следующие параметры устанавливают ограничения для пула удалённых обслуживающих процессов. Удалённые обслуживающие процессы — это логические каналы, которые могут быть установлены через мультиплексированное соединение между узлами кластера для проксирования запросов от ведомого узла (последователя) к ведущему узлу (лидеру). Настройка этих параметров может быть необходима только для кластеров из нескольких узлов. Значения по умолчанию являются оптимальными и их не рекомендуется изменять.

proxima.backend_pool_remote_total_limit (integer) #

Устанавливает максимальное число логических каналов между узлами кластера для проксирования запросов клиента. Диапазон допустимых значений: от 1 до 2^32-1. Значение по умолчанию — 100000.

proxima.backend_pool_remote_bucket_limit (integer) #

Устанавливает максимальное число логических каналов между узлами кластера для проксирования клиентских запросов в рамках подключений, идентифицированных связкой user + database. Диапазон допустимых значений: от 1 до значения, указанного в proxima.backend_pool_remote_total_limit. Значение по умолчанию — 1000.

proxima.backend_pool_remote_overdue_interval (float) #

Устанавливает время бездействия удалённого обслуживающего процесса в секундах. Если удалённый обслуживающий процесс не используется клиентами дольше, чем установлено этим параметром, логическое соединение между узлами кластера будет разорвано. Диапазон допустимых значений от 1.0 до 86400.0. Значение по умолчанию — 60.0.

F.70.6. Метрики мониторинга #

Все метрики мониторинга proxima разделены на несколько классов, чтобы их было удобно запрашивать через представления метрик.

Доступны следующие классы:

F.70.6.1. Представления метрик мониторинга #

При использовании в BiHA-кластере, proxima регистрирует схему proxima в базе данных biha_db, где создаёт представления для запроса метрик.

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

F.70.6.2. Метрики потоков #

Метрики потоков отображают использование ресурсов процессора потоками proxima, а также метрики корутинового движка, на котором основана proxima. Количество счётчиков, которые используются в этом классе, зависит от количества запущенных потоков.

Имена метрик потоков имеют структуру thread.ID.имя_счётчика, где ID — внутренний идентификатор корутинового движка.

Доступны следующие счётчики:

Таблица F.52. Счётчики потоков

ИмяТипОписание
thread.ID.active_time_nsИнтегральныйКоличество наносекунд, в течение которого поток исполнял какую-либо полезную нагрузку.
thread.ID.purged_coroutinesИнтегральныйКоличество контекстов корутин, которые были разрушены из-за длительной невостребованности.
thread.ID.transferred_coroutines_acceptedИнтегральныйКоличество контекстов корутин, перенесённых для исполнения на этот поток.
thread.ID.wakeup_requests_acceptedИнтегральныйКоличество принятых запросов на пробуждение корутины.
thread.ID.futex_wakeup_requests_acceptedИнтегральныйКоличество принятых запросов на пробуждение корутины, заблокированной на фьютексе (futex).
thread.ID.active_coroutines_calledИнтегральныйКоличество вызовов активных корутин. Если удвоить это значение, можно получить количество переключений контекстов корутин в текущем потоке.
thread.ID.evrun_onceИнтегральныйКоличество вызовов библиотеки libev c блокировкой потока для ожидания событий, относящихся к вводу-выводу или активным таймерам.
thread.ID.evrun_nowaitИнтегральныйКоличество вызовов библиотеки libev без блокировки потока для ожидания событий, относящихся к вводу-выводу или активным таймерам.
thread.ID.scheduler.coroctx_in_useМгновенное значениеКоличество контекстов корутин, которые используются в настоящий момент.
thread.ID.scheduler.coroctx_cachedМгновенное значениеКоличество контекстов корутин, которые в текущий момент кешированны и не используются, но могут быть быстро предоставлены при создании новых корутин.
thread.ID.scheduler.cs_activeМгновенное значениеКоличество активных корутин.
thread.ID.scheduler.cs_inactiveМгновенное значениеКоличество корутин в неактивном состоянии.
thread.ID.scheduler.cs_waiting_futexМгновенное значениеКоличество корутин в ожидании фьютекса.
thread.ID.scheduler.cs_wakeup_futexМгновенное значениеКоличество корутин в очереди пробуждения при блокировке на фьютексе.
thread.ID.scheduler.cs_waiting_ioМгновенное значениеКоличество корутин в ожидании доступности чтения или записи на устройстве ввода-вывода или активации таймера (например, при блокировке в операции sleep).

Пример результата запроса метрик потоков выглядит следующим образом:

                   name                   |    class    | node_id |   value
------------------------------------------+-------------+---------+------------
 thread.1.active_time_ns                  | thread-load |       0 | 6319387757
 thread.1.purged_coroutines               | thread-load |       0 |          1
 thread.1.transferred_coroutines_accepted | thread-load |       0 |          2
 thread.1.wakeup_requests_accepted        | thread-load |       0 |          0
 thread.1.futex_wakeup_requests_accepted  | thread-load |       0 |      10214
 thread.1.active_coroutines_called        | thread-load |       0 |      32385
 thread.1.evrun_once                      | thread-load |       0 |      17162
 thread.1.evrun_nowait                    | thread-load |       0 |       4567
 thread.1.scheduler.coroctx_in_use        | thread-load |       0 |         19
 thread.1.scheduler.coroctx_cached        | thread-load |       0 |          1
 thread.1.scheduler.cs_active             | thread-load |       0 |          1
 thread.1.scheduler.cs_inactive           | thread-load |       0 |          1
 thread.1.scheduler.cs_waiting_futex      | thread-load |       0 |          5
 thread.1.scheduler.cs_wakeup_futex       | thread-load |       0 |          0
 thread.1.scheduler.cs_waiting_io         | thread-load |       0 |         12
 thread.2.active_time_ns                  | thread-load |       0 |     974064
 thread.2.purged_coroutines               | thread-load |       0 |          0
 thread.2.transferred_coroutines_accepted | thread-load |       0 |          0
 thread.2.wakeup_requests_accepted        | thread-load |       0 |          0
 thread.2.futex_wakeup_requests_accepted  | thread-load |       0 |          6
 thread.2.active_coroutines_called        | thread-load |       0 |          7
 thread.2.evrun_once                      | thread-load |       0 |        109
 thread.2.evrun_nowait                    | thread-load |       0 |          0
 thread.2.scheduler.coroctx_in_use        | thread-load |       0 |          1
 thread.2.scheduler.coroctx_cached        | thread-load |       0 |          0
 thread.2.scheduler.cs_active             | thread-load |       0 |          0
 thread.2.scheduler.cs_inactive           | thread-load |       0 |          0
 thread.2.scheduler.cs_waiting_futex      | thread-load |       0 |          1
 thread.2.scheduler.cs_wakeup_futex       | thread-load |       0 |          0
 thread.2.scheduler.cs_waiting_io         | thread-load |       0 |          0
 ...

F.70.6.3. Метрики трафика #

Метрики трафика отображают байты и/или сообщения, которые передаются через канал связи, а также количество сброшенных сообщений и повторных подключений, если они поддерживаются текущим каналом связи.

Имена метрик трафика имеют структуру traffic.CHANNEL.COUNTER, где:

  • CHANNEL — канал, данные которого отображаются в результате запроса. Поддерживаются следующие каналы:

    • fe (frontend) — передача данных между всеми клиентами и proxima.

    • be (backend) — данные, передаваемые между proxima и обслуживающими процессами proxima.

    • rpc (RPC, Remote Procedure Call) — данные, передаваемые между proxima и другими процессами текущего экземпляра базы данных.

    • nodeID.client — данные, передаваемые через клиентское подключение между текущим узлом и узлом с идентификатором ID.

    • nodeID.server — данные, передаваемые через серверное подключение между текущим узлом и узлом с идентификатором ID.

  • COUNTER — имя счётчика.

Доступны следующие счётчики:

Таблица F.53. Счётчики трафика

ИмяТипОписание
traffic.CHANNEL.rx_bytesИнтегральныйКоличество байтов, принятых по каналу связи.
traffic.CHANNEL.tx_bytesИнтегральныйКоличество байтов, отправленных по каналу связи.
traffic.CHANNEL.rx_msgsИнтегральныйКоличество принятых сообщений. Этот счётчик присутствует, только если канал поддерживает отслеживание отдельных сообщений.
traffic.CHANNEL.tx_msgsИнтегральныйКоличество отправленных сообщений. Этот счётчик присутствует, только если канал поддерживает отслеживание отдельных сообщений.
traffic.CHANNEL.rx_msgs_droppedИнтегральныйКоличество сброшенных сообщений. Этот счётчик присутствует, только если канал поддерживает сброс сообщений (dropping).
traffic.CHANNEL.reconnectsИнтегральныйКоличество повторных подключений после сбоев. Этот счётчик присутствует, только если канал поддерживает повторные подключения.

Пример результата запроса метрик трафика выглядит следующим образом:

                 name                 |  class  | node_id |  value
--------------------------------------+---------+---------+----------
 traffic.fe.rx_bytes                  | traffic |       0 |      943
 traffic.fe.tx_bytes                  | traffic |       0 |    10632
 traffic.be.rx_bytes                  | traffic |       0 |    13233
 traffic.be.tx_bytes                  | traffic |       0 |     2099
 traffic.node1.client.rx_bytes        | traffic |       0 |       32
 traffic.node1.client.tx_bytes        | traffic |       0 | 64641815
 traffic.node1.client.rx_msgs         | traffic |       0 |      124
 traffic.node1.client.tx_msgs         | traffic |       0 |     7868
 traffic.node1.client.rx_msgs_dropped | traffic |       0 |        0
 traffic.node1.client.reconnects      | traffic |       0 |        1
 traffic.node2.client.rx_bytes        | traffic |       0 |       32
 traffic.node2.client.tx_bytes        | traffic |       0 | 64609591
 traffic.node2.client.rx_msgs         | traffic |       0 |      124
 traffic.node2.client.tx_msgs         | traffic |       0 |     7864
 traffic.node2.client.rx_msgs_dropped | traffic |       0 |        0
 traffic.node2.client.reconnects      | traffic |       0 |        1
 traffic.rpc.rx_bytes                 | traffic |       0 |      100
 traffic.rpc.tx_bytes                 | traffic |       0 |    12416
 traffic.rpc.rx_msgs                  | traffic |       0 |        3
 traffic.rpc.tx_msgs                  | traffic |       0 |        2
 traffic.node2.server.rx_bytes        | traffic |       0 | 56532348
 traffic.node2.server.tx_bytes        | traffic |       0 |       32
 traffic.node2.server.rx_msgs         | traffic |       0 |     7868
 traffic.node2.server.tx_msgs         | traffic |       0 |      124
 traffic.node2.server.rx_msgs_dropped | traffic |       0 |        0
 traffic.node2.server.reconnects      | traffic |       0 |        1
 traffic.node1.server.rx_bytes        | traffic |       0 | 56504900
 traffic.node1.server.tx_bytes        | traffic |       0 |       32
 traffic.node1.server.rx_msgs         | traffic |       0 |     7864
 traffic.node1.server.tx_msgs         | traffic |       0 |      124
 traffic.node1.server.rx_msgs_dropped | traffic |       0 |        0
 traffic.node1.server.reconnects      | traffic |       0 |        1

F.70.6.4. Метрики пула обслуживающих процессов #

Метрики пула обслуживающих процессов отображают характеристики запросов клиентов к пулу на предоставление обслуживающих процессов.

Имена метрик пула обслуживающих процессов имеют структуру backend_pool.SCOPE.COUNTER, где:

  • SCOPE определяет тип обслуживающего процесса: локальный или удалённый.

  • COUNTER — имя счётчика.

Доступны следующие счётчики:

Таблица F.54. Счётчики пула обслуживающих процессов

ИмяТипОписание
backend_pool.SCOPE.requestsИнтегральныйКоличество запросов на предоставление обслуживающих процессов к пулу обслуживающих процессов.
backend_pool.SCOPE.creationsИнтегральныйКоличество новых обслуживающих процессов, созданных при запросе у пула.
backend_pool.SCOPE.destructionsИнтегральныйКоличество разрушений (закрытий) обслуживающих процессов. Может случиться, когда обслуживающий процесс вытесняется из бакета пула или не используется долгое время.
backend_pool.SCOPE.unlinksИнтегральныйКоличество обслуживающих процессов, отвязанных от пула.
backend_pool.SCOPE.acquisitionsИнтегральныйКоличество обслуживающих процессов, предоставленных клиентам.
backend_pool.SCOPE.releasesИнтегральныйКоличество обслуживающих процессов, возвращённых клиентами в пул. В случае ряда ошибок обслуживающий процесс может быть разрушен клиентом, а не возвращён в пул. Это вызовет рост значения backend_pool.SCOPE.unlinks, но не backend_pool.SCOPE.releases.
backend_pool.SCOPE.stealsИнтегральныйКоличество «краж» обслуживающих процессов из других бакетов пула. Интенсивный рост этого значения означает, что система испытывает высокую нагрузку на множестве различных баз данных и/или от множества различных пользователей. Это указывает на недостаточный размер пула для текущей нагрузки, что приводит к деградации производительности системы.
backend_pool.SCOPE.errorsИнтегральныйКоличество ошибок, возникших при запросе обслуживающих процессов из пула. Это обобщённый счётчик. В некоторых случаях ошибки могут вызвать разрыв клиентских подключений. В других случаях ошибка может привести к повторению запроса обслуживающего процесса и быть прозрачной для клиента. Например, если пул отказывает в предоставлении обслуживающего процесса, так как его невозможно создать по причине превышения лимита max_connections, клиент будет ожидать в очереди.
backend_pool.SCOPE.request_duration.p*Процентиль (окно: T = 60 секунд, C = 1000 событий)Процентили времени между запросом обслуживающего процесса и фактическим предоставлением обслуживающего процесса клиенту. Это совокупный счётчик, значения которого могут сильно отличаться. Например, предоставление свободного обслуживающего процесса из пула может занимать микросекунды, создание нового — миллисекунды. Но если пул перегружен, и клиент должен ждать выполнения предыдущего запроса к базе данных, это может занять секунды, минуты, и даже часы. Другими словами, этот счётчик показывает распределение времени ожидания в очереди пула перед выполнением запроса.

Пример результата запроса метрик пула обслуживающих процессов выглядит следующим образом:

                   name                    |    class     | node_id |         value
-------------------------------------------+--------------+---------+------------------------
 backend_pool.local.requests               | backend-pool |       0 |                     13
 backend_pool.local.creations              | backend-pool |       0 |                      5
 backend_pool.local.destructions           | backend-pool |       0 |                      3
 backend_pool.local.unlinks                | backend-pool |       0 |                      4
 backend_pool.local.acquisitions           | backend-pool |       0 |                     12
 backend_pool.local.releases               | backend-pool |       0 |                     10
 backend_pool.local.steals                 | backend-pool |       0 |                      0
 backend_pool.local.errors                 | backend-pool |       0 |                      1
 backend_pool.local.request_duration.p0    | backend-pool |       0 |   8.74983775227453e-06
 backend_pool.local.request_duration.p5    | backend-pool |       0 |  8.765000496725975e-06
 backend_pool.local.request_duration.p25   | backend-pool |       0 |  9.654992595293691e-06
 backend_pool.local.request_duration.p50   | backend-pool |       0 | 1.0727600464262677e-05
 backend_pool.local.request_duration.p75   | backend-pool |       0 | 1.1514681787272259e-05
 backend_pool.local.request_duration.p95   | backend-pool |       0 |   0.008438241305000952
 backend_pool.local.request_duration.p100  | backend-pool |       0 |   0.008452788451603185
 backend_pool.remote.requests              | backend-pool |       0 |                      0
 backend_pool.remote.creations             | backend-pool |       0 |                      0
 backend_pool.remote.destructions          | backend-pool |       0 |                      0
 backend_pool.remote.unlinks               | backend-pool |       0 |                      0
 backend_pool.remote.acquisitions          | backend-pool |       0 |                      0
 backend_pool.remote.releases              | backend-pool |       0 |                      0
 backend_pool.remote.steals                | backend-pool |       0 |                      0
 backend_pool.remote.errors                | backend-pool |       0 |                      0
 backend_pool.remote.request_duration.p0   | backend-pool |       0 |                      0
 backend_pool.remote.request_duration.p5   | backend-pool |       0 |                      0
 backend_pool.remote.request_duration.p25  | backend-pool |       0 |                      0
 backend_pool.remote.request_duration.p50  | backend-pool |       0 |                      0
 backend_pool.remote.request_duration.p75  | backend-pool |       0 |                      0
 backend_pool.remote.request_duration.p95  | backend-pool |       0 |                      0
 backend_pool.remote.request_duration.p100 | backend-pool |       0 |                      0

F.70.6.5. Метрики клиентских подключений #

Метрики клиентских подключений включают счётчики подключений и их характеристики для различных каналов связи.

Имена метрик клиентских подключений имеют структуру client.CHANNEL.COUNTER, где:

  • CHANNEL — канал связи, данные которого отображаются в результате запроса. Поддерживаются следующие каналы:

    • lfe (local frontend) — клиенты, которые подключаются к proxima через один из портов для выполнения SQL-запросов.

    • lbe (local backend) — обслуживающие процессы Postgres Pro Enterprise, созданные proxima.

    • rfe (remote frontend) — клиенты, перенаправленные на текущий узел с другого узла.

    • rbe (remote backend) — внутренние каналы связи, созданные расширением proxima для перенаправления запросов на удалённый узел.

    • rpc (RPC, Remote Procedure Call) — данные, передаваемые между proxima и другими процессами текущего экземпляра базы данных.

  • COUNTER — имя счётчика.

Доступны следующие счётчики:

Таблица F.55. Счётчики клиентских подключений

ИмяТипОписание
client.lfe.now_connectedМгновенное значениеКоличество клиентов, фактически подключённых к текущему узлу.
client.lfe.acceptedИнтегральныйКоличество клиентов с успешно аутентифицированными подключениями.
client.lfe.rejectedИнтегральныйКоличество клиентов с отклонёнными подключениями, в основном из-за ошибок аутентификации.
client.lfe.disconnectedИнтегральныйКоличество клиентов с закрытыми подключениями.
client.lfe.auth_passwordИнтегральныйКоличество клиентов, аутентифицированных по паролю.
client.lfe.auth_md5ИнтегральныйКоличество клиентов, аутентифицированных по методу MD5.
client.lfe.auth_scram_sha256ИнтегральныйКоличество клиентов, аутентифицированных по методу SCRAM-SHA-256.
client.lfe.auth_trustИнтегральныйКоличество клиентов, подключение от которых попало под правила HBA в категории доверенных.
client.lfe.auth_tls_acceptedИнтегральныйКоличество принятых TLS-подключений.
client.lfe.auth_tls_rejectedИнтегральныйКоличество отклонённых TLS-подключений.
client.lfe.auth_duration.p*Процентиль (окно: T = 60 секунд, C = 1000 событий)Распределение времени для процедуры аутентификации клиентов.
client.lbe.enter_dedicatedИнтегральныйКоличество подключений обслуживающих процессов, перешедших в выделенный сеанс.
client.lbe.leave_dedicatedИнтегральныйКоличество подключений обслуживающих процессов, покинувших выделенный сеанс.
client.lbe.dedicated_duration.p*Процентиль (окно: T = 60 секунд, C = 1000 событий)Распределение времени для подключений, оставшихся в выделенном сеансе.
client.rfe.now_connectedМгновенное значениеФактическое количество клиентов, перенаправленных на текущий узел для выполнения запроса.
client.rfe.connectedИнтегральныйКоличество клиентов, перенаправленных на текущий узел для выполнения запроса.
client.rfe.disconnectedИнтегральныйКоличество клиентов с закрытыми подключениями.
client.rbe.enter_dedicatedИнтегральныйКоличество подключений обслуживающих процессов, перешедших в выделенный сеанс.
client.rbe.leave_dedicatedИнтегральныйКоличество подключений обслуживающих процессов, покинувших выделенный сеанс.
client.rbe.dedicated_duration.p*Процентиль (окно: T = 60 секунд, C = 1000 событий)Распределение времени для подключений, оставшихся в выделенном сеансе.
client.rpc.now_connectedМгновенное значениеКоличество клиентов, подключённых в настоящий момент.
client.rpc.acceptedИнтегральныйКоличество клиентов с успешно принятыми подключениями с учётом прохождения процедуры аутентификации.
client.rpc.rejectedИнтегральныйКоличество клиентов с отклонёнными подключениями, в основном из-за ошибок аутентификации.
client.rpc.disconnectedИнтегральныйКоличество клиентов с закрытыми подключениями.

Пример результата запроса метрик клиентских подключений выглядит следующим образом:

                name                | class  | node_id | value
------------------------------------+--------+---------+-------
 client.lfe.now_connected           | client |       0 |     1
 client.lfe.accepted                | client |       0 |     1
 client.lfe.rejected                | client |       0 |     0
 client.lfe.disconnected            | client |       0 |     0
 client.lfe.auth_password           | client |       0 |     0
 client.lfe.auth_md5                | client |       0 |     0
 client.lfe.auth_scram_sha256       | client |       0 |     0
 client.lfe.auth_trust              | client |       0 |     1
 client.lfe.auth_tls_accepted       | client |       0 |     0
 client.lfe.auth_tls_rejected       | client |       0 |     0
 client.rfe.now_connected           | client |       0 |     0
 client.rfe.connected               | client |       0 |     0
 client.rfe.disconnected            | client |       0 |     0
 client.lbe.enter_dedicated         | client |       0 |     0
 client.lbe.leave_dedicated         | client |       0 |     0
 client.rbe.enter_dedicated         | client |       0 |     0
 client.rbe.leave_dedicated         | client |       0 |     0
 client.rpc.now_connected           | client |       0 |     1
 client.rpc.accepted                | client |       0 |     5
 client.rpc.rejected                | client |       0 |     0
 client.rpc.disconnected            | client |       0 |     4
 client.lfe.auth_duration.p0        | client |       0 |     0
 client.lfe.auth_duration.p5        | client |       0 |     0
 client.lfe.auth_duration.p25       | client |       0 |     0
 client.lfe.auth_duration.p50       | client |       0 |     0
 client.lfe.auth_duration.p75       | client |       0 |     0
 client.lfe.auth_duration.p95       | client |       0 |     0
 client.lfe.auth_duration.p100      | client |       0 |     0
 client.lbe.dedicated_duration.p0   | client |       0 |     0
 client.lbe.dedicated_duration.p5   | client |       0 |     0
 client.lbe.dedicated_duration.p25  | client |       0 |     0
 client.lbe.dedicated_duration.p50  | client |       0 |     0
 client.lbe.dedicated_duration.p75  | client |       0 |     0
 client.lbe.dedicated_duration.p95  | client |       0 |     0
 client.lbe.dedicated_duration.p100 | client |       0 |     0
 client.rbe.dedicated_duration.p0   | client |       0 |     0
 client.rbe.dedicated_duration.p5   | client |       0 |     0
 client.rbe.dedicated_duration.p25  | client |       0 |     0
 client.rbe.dedicated_duration.p50  | client |       0 |     0
 client.rbe.dedicated_duration.p75  | client |       0 |     0
 client.rbe.dedicated_duration.p95  | client |       0 |     0
 client.rbe.dedicated_duration.p100 | client |       0 |     0

F.70.6.6. Метрики RPC-сервера #

Доступны следующие счётчики:

Таблица F.56. Счётчики RPC-сервера

ИмяТипОписание
rpc.call_duration.p*Процентиль (окно: T = 60 секунд, C = 1000 событий)Время распределения выполнения команд.
rpc.err_not_foundИнтегральныйКоличество вызовов несуществующих функций.

Пример результата запроса метрик RPC-сервера выглядит следующим образом:

            name          | class | node_id |         value
  ------------------------+-------+---------+------------------------
   rpc.call_duration.p0   | rpc   |       0 |  4.315190768277686e-05
   rpc.call_duration.p5   | rpc   |       0 |  4.331642078668621e-05
   rpc.call_duration.p25  | rpc   |       0 |  6.386338595749277e-05
   rpc.call_duration.p50  | rpc   |       0 |   7.37059571607683e-05
   rpc.call_duration.p75  | rpc   |       0 |  8.217731456416661e-05
   rpc.call_duration.p95  | rpc   |       0 | 0.00011075225182228674
   rpc.call_duration.p100 | rpc   |       0 | 0.00011117317272816024
   rpc.err_not_found      | rpc   |       0 |                      0
Пред. Наверх След.
F.69. postgres_fdw — обращение к данным, находящимся на внешних серверах Postgres Pro Начало F.71. ptrack — механизм резервного копирования базы Postgres Pro на уровне блоков