Мониторинг и логи в Managed Service for PostgreSQL

• Где я могу отслеживать использование дискового пространства, чтобы не превысить лимит в 95% для перехода в read-only?

• Логи хранятся на том же диске, что и данные PostgreSQL? Как они тарифицируются?

• Как долго хранятся логи?

• Как включить логирование SQL-запросов?

• Что такое WAL и для чего они нужны?

• Что означает параметр Cached в мониторинге RAM хоста кластера PostgreSQL?

• Как получать алерты о критических показателях кластера PostgreSQL?

• Как настроить алерт, который срабатывает при заполнении определенного процента дискового пространства?

Где я могу отслеживать использование дискового пространства, чтобы не превысить лимит в 95% для перехода в read-only?Где я могу отслеживать использование дискового пространства, чтобы не превысить лимит в 95% для перехода в read-only?

Отслеживать использование дискового пространства можно:

• в консоли управления с помощью инструментов мониторинга состояния кластера;
• в сервисе Yandex Monitoring с возможностью настроить алерты по заданным метрикам.

Логи хранятся на том же диске, что и данные PostgreSQL? Как они тарифицируются?Логи хранятся на том же диске, что и данные PostgreSQL? Как они тарифицируются?

Логи хранятся отдельно от диска с данными и ротируются автоматически. Посмотреть информацию о логах можно командой CLI:

yc managed-postgresql cluster list-logs <идентификатор_кластера>

Использование хранилища с логами кластера не тарифицируется.

Как долго хранятся логи?Как долго хранятся логи?

Логи кластера хранятся 45 дней.

Как включить логирование SQL-запросов?Как включить логирование SQL-запросов?

Чтобы включить логирование SQL-запросов:

1. Убедитесь, что в базе данных установлено расширение pg_stat_statements. Если расширение не установлено, добавьте его.

   При использовании CLI выполните команду:

   yc managed-postgresql database update <имя_БД> \
      --cluster-name <имя_кластера> \
      --extensions <список_установленных_расширений>,pg_stat_statements
   

   В параметре --extensions укажите pg_stat_statements и все остальные расширения, которые должны остаться включенными. Если в базе данных нет других расширений, укажите только pg_stat_statements.

2. Измените настройки СУБД:

   • Установите для параметра Log min duration statement значение 60000 мс. В лог будут попадать запросы, время выполнения которых составляет одну минуту или больше. При необходимости постепенно уменьшайте значение. Значение 0 включает логирование всех запросов и может значительно увеличить объем логов и нагрузку на кластер.
   • Установите для параметра Auto explain sample rate значение 1.
   • Если нужно записывать в лог планы выполнения запросов, добавьте auto_explain в параметр Shared preload libraries, установите для параметра Auto explain log min duration значение 60000 мс и включите параметр Auto explain log analyze.

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

   yc managed-postgresql cluster update-config <имя_или_идентификатор_кластера> \
      --set log_min_duration_statement=60000 \
      --set auto_explain_sample_rate=1 \
      --set auto_explain_log_min_duration=60000 \
      --set auto_explain_log_analyze=true \
      --set shared_preload_libraries=SHARED_PRELOAD_LIBRARIES_AUTO_EXPLAIN
   

   Если планы выполнения запросов не нужны, не передавайте параметры auto_explain_log_min_duration, auto_explain_log_analyze и shared_preload_libraries. Если к кластеру уже подключены другие библиотеки общего пользования, укажите их вместе с SHARED_PRELOAD_LIBRARIES_AUTO_EXPLAIN в параметре shared_preload_libraries.

3. Посмотрите записи в логах кластера. Для этого достаточно прав на просмотр логов в кластере. Чтобы выполнять запросы к представлению pg_stat_statements, достаточно иметь право на подключение к базе данных — роль mdb_monitor не требуется.

Что такое WAL и для чего они нужны?Что такое WAL и для чего они нужны?

Журналы Write-Ahead Log нужны для записи данных на диск и их репликации. Они создаются при запросах на запись и занимают место на диске до момента полной записи информации с журналов на диски хостов — это обеспечивает отказоустойчивость и надежность СУБД.

Подробнее о принципах работы PostgreSQL читайте в официальной документации.

Что означает параметр Cached в мониторинге RAM хоста кластера PostgreSQL?Что означает параметр Cached в мониторинге RAM хоста кластера PostgreSQL?

В Cached помещаются кешированные данные. Большинство операций выполняется на уровне оперативной памяти, так как вся информация базы данных хранится именно там. Кеширование происходит не только для баз данных, но и для диска — из-за этого объём кешированных данных может превышать размер хранилища.

В случае увеличения потребления оперативной памяти приложениями часть памяти с кешем может высвобождаться.

Подробнее о кешировании данных дисков в Linux читайте в документации.

Как получать алерты о критических показателях кластера PostgreSQL?Как получать алерты о критических показателях кластера PostgreSQL?

Воспользуйтесь сервисом Yandex Monitoring и настройте алерты по критичным для вас параметрам.

Как настроить алерт, который срабатывает при заполнении определенного процента дискового пространства?Как настроить алерт, который срабатывает при заполнении определенного процента дискового пространства?

Создайте алерт с метрикой disk.used_bytes в сервисе Yandex Monitoring. Метрика показывает размер использованного дискового пространства в кластере Managed Service for PostgreSQL.

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

• Alarm — 90% дискового пространства.
• Warning — 80% дискового пространства.

Значения порогов задаются только в байтах. Например, рекомендуемые значения для диска размером в 100 ГБ:

• Alarm — 96636764160 байт (90%).
• Warning — 85899345920 байт (80%).