Задачи администрирования
Мониторинг
16
Авторские права
© Postgres Professional, 2017–2024
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов, Алексей Береснев
Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
edu@postgrespro.ru
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Средства операционной системы
Накопительная статистика сервера
Журнал сообщений сервера
Внешние системы мониторинга
3
Средства ОС
Процессы
ps, pgrep...
параметр update_process_title для обновления статуса процессов
параметр cluster_name для установки имени кластера
Использование ресурсов
iostat, vmstat, sar, top...
Дисковое пространство
df, du, quota...
PostgreSQL работает под управлением операционной системы и
в известной степени зависит от ее настроек.
Используя инструменты операционной системы, можно посмотреть
информацию о процессах PostgreSQL. При включенном (по умолчанию)
параметре сервера update_process_title в имени процесса отображается
его текущее состояние. Параметр cluster_name задает имя экземпляра,
по которому его можно отличать в списке процессов.
Использование системных ресурсов (процессора, ОЗУ, дисков) в Unix
проверяют с помощью iostat, vmstat, sar, top и других инструментов.
Необходимо следить и за размером дискового пространства. Место,
занимаемое базой данных, можно смотреть как из самой БД (см.
модуль «Организация данных»), так из ОС (команда du). Размер
доступного дискового пространства надо смотреть в ОС (команда df).
Дисковые квоты Unix ограничивают использование диска
пользователями ОС. Так как процессы PostgreSQL принадлежат
единственному пользователю postgres (по умолчанию), дисковая квота
для него должна быть достаточной. PostgreSQL не позволяет
квотировать использование ролями дискового пространства.
В целом набор инструментов и подходы могут сильно различаться
в зависимости от используемой ОС и файловой системы, поэтому
подробно здесь не рассматриваются.
4
Накопительная статистика
Процесс сбора статистики
Текущие активности системы
Отслеживание выполнения команд
Дополнительные расширения
Существует два основных источника информации о происходящем
в системе. Первый из них — статистическая информация, которая
собирается PostgreSQL и хранится в кластере.
5
Сбор статистики
Настройки накопительной статистики
параметр действие
track_activities включает мониторинг текущих команд
track_counts сбор статистики по обращениям к таблицам
и индексам
track_functions отслеживание использования пользовательских
функций
выключен по умолчанию
track_io_timing мониторинг времени чтения и записи блоков
выключен по умолчанию
track_wal_io_timing мониторинг времени записи WAL
выключен по умолчанию
Система накопительной статистики в PostgreSQL собирает и позволяет
получать информацию о работе сервера. Накопительная статистика
отслеживает обращения к таблицам и индексам как на уровне блоков
на диске, так и на уровне отдельных строк. Кроме того, для каждой
таблицы собираются сведения о количестве строк и действиях по
очистке и анализу.
Можно также учитывать количество вызовов пользовательских функций
и время, затраченное на их выполнение.
Количеством собираемой информации управляют несколько
параметров сервера, так как чем больше информации собирается, тем
больше и накладные расходы.
6
Архитектура
серверный
процесс
серверный
процесс
обслуживающий
процесс
разделяемая
память
статистика
транзакции
между транзакциями
накопительная
статистика
PGDATA/pg_stat/
снимок
статистики
stats_fetch_consistency
при штатной
остановке сервера
накопительная
статистика
none
cache
snapshot
Обслуживающие процессы собирают статистику в рамках транзакций.
Затем эта статистика самим процессом записывается в разделяемую
память, но не чаще, чем раз в одну секунду (задано при компиляции).
Накопительная статистика запоминается в PGDATA/pg_stat/ при
штатной остановке сервера и считывается при его запуске. При
аварийной остановке все счетчики сбрасываются.
Обслуживающий процесс может кешировать данные статистики при
обращении к ней. Уровнем кеширования управляет параметр
stats_fetch_consistency:
●
none — без кеширования, статистика только в разделяемой памяти;
●
cache — кешируется статистика по одному объекту;
●
snapshot — кешируется вся статистика текущей базы данных.
По умолчанию используется значение cache — это компромисс между
согласованностью и эффективностью.
Закешированная статистика не перечитывается и сбрасывается в конце
транзакции или при вызове pg_stat_clear_snapshot().
Из-за задержек и кеширования обслуживающий процесс использует не
самую свежую статистику, но обычно это и не требуется.
8
Текущие активности
Настройка
статистика параметр
текущие активности track_activities
и ожидания обслуживающих включен по умолчанию
и фоновых процессов
Текущие активности всех обслуживающих и фоновых процессов
отображаются в представлении pg_stat_activity. Подробнее на нем мы
остановимся в демонстрации.
Работа этого представления зависит от параметра track_activities,
включенного по умолчанию.
10
Выполнение команд
Представления для отслеживания выполнения
команда представление
ANALYZE pg_stat_progress_analyze
CREATE INDEX, REINDEX pg_stat_progress_create_index
VACUUM pg_stat_progress_vacuum
включая процессы автоочистки
CLUSTER, VACUUM FULL pg_stat_progress_cluster
Создание базовой резервной копии pg_stat_progress_basebackup
COPY pg_stat_progress_copy
Следить за ходом выполнения некоторых потенциально долгих команд
можно, выполняя запросы к соответствующим представлениям.
Структуры представлений описаны в документации:
Создание резервных копий рассматривается в модуле «Резервное
копирование».
11
Дополнительная статистика
Расширения в поставке
pg_stat_statements статистика по запросам
pgstattuple статистика по версиям строк
pg_buffercache состояние буферного кеша
Другие расширения
pg_wait_sampling статистика ожиданий
pg_stat_kcache статистика по процессору и вводу-выводу
pg_qualstats статистика по предикатам
…
Существуют расширения, позволяющие собирать дополнительную
статистику, как входящие в поставку, так и внешние.
Например, расширение pg_stat_statements сохраняет информацию
о запросах, выполняемых СУБД; pg_buffercache позволяет заглянуть
в содержимое буферного кеша и т. п.
Многие важные расширения рассматриваются в курсах DBA2 и DEV2.
12
Журнал сообщений
Настройка журнальных записей
Ротация файлов журнала
Анализ журнала
Второй важный источник информации о происходящем на сервере —
журнал сообщений.
13
Журнал сообщений
Приемник сообщений (log_destination = список)
stderr поток ошибок
csvlog формат CSV (только с коллектором)
jsonlog формат JSON (только с коллектором)
syslog демон syslog
eventlog журнал событий Windows
Коллектор сообщений (logging_collector = on)
позволяет собирать дополнительную информацию
никогда не теряет сообщения (в отличие от syslog)
записывает stderr, csvlog и jsonlog в файл log_directory/log_filename
Журнал сообщений сервера можно направлять в разные приемники и
выводить в разных форматах. Основной параметр, который определяет
приемник и формат — log_destination (можно указать один или
несколько приемников через запятую).
Значение stderr (установленное по умолчанию) выводит сообщения
в стандартный поток ошибок в текстовом виде. Значение syslog
направляет сообщения демону syslog в Unix-системах, а eventlog —
в журнал событий Windows.
Обычно дополнительно включают специальный процесс — коллектор
сообщений. Он позволяет записать больше информации, поскольку
собирает ее со всех процессов, составляющих PostgreSQL. Он
спроектирован так, что никогда не теряет сообщения; как следствие,
при большой нагрузке он может стать узким местом.
Коллектор сообщений включается параметром logging_collector. При
значении stderr информация записывается в каталог, определяемый
параметром log_directory, в файл, определяемый параметром
log_filename.
Включенный коллектор сообщений позволяет также указать приемник
csvlog; в этом случае информация будет сбрасываться в формате CSV
в файл log_filename с расширением csv. При использовании приемника
jsonlog содержимое файла отчета будет записываться в формате JSON,
а имя файла будет иметь расширение json.
14
Информация в журнале
Настройки
информация параметр
сообщения определенного уровня log_min_messages
время выполнения длинных команд log_min_duration_statement
время выполнения команд log_duration
имя приложения application_name
контрольные точки log_checkpoints
подключения и отключения log_(dis)connections
длинные ожидания log_lock_waits
текст выполняемых команд log_statement
использование временных файлов log_temp_files
...
В журнал сообщений сервера можно выводить множество полезной
информации. По умолчанию почти весь вывод отключен, чтобы не
превратить запись журнала в узкое место для подсистемы ввода-
вывода. Администратор должен решить, какая информация важна,
обеспечить необходимое место на диске для ее хранения и оценить
влияние записи журнала на общую производительность системы.
15
Ротация файлов журнала
С помощью коллектора сообщений
настройка параметр
маска имени файла log_filename
время ротации, мин log_rotation_age
размер файла для ротации, КБ log_rotation_size
перезаписывать ли файлы log_truncate_on_rotation = on
комбинируя маску файла и время ротации, получаем разные схемы:
'postgresql-%H.log', '1h' 24 файла в сутки
'postgresql-%a.log', '1d' 7 файлов в неделю
Внешние средства
системная утилита logrotate
Если записывать журнал в один файл, рано или поздно он вырастет
до огромных размеров, что крайне неудобно для администрирования
и анализа. Поэтому обычно используется та или иная схема ротации
журналов.
Коллектор сообщений имеет встроенные средства ротации, которые
настраиваются несколькими параметрами, основные из которых
приведены на слайде.
Параметр log_filename позволяет задавать не просто имя, а маску
имени файла с помощью спецсимволов даты и времени.
Параметр log_rotation_age задает время переключения на следующий
файл в минутах (а log_rotation_size — размер файла, при котором надо
переключаться на следующий).
Включение log_truncate_on_rotation перезаписывает уже существующие
файлы.
Таким образом, комбинируя маску и время переключения, можно
получать разные схемы ротации.
В качестве альтернативы можно воспользоваться внешними
программами ротации, например пакетный дистрибутив для Ubuntu
использует системную утилиту logrotate (ее настройки находятся в
файле /etc/logrotate.d/postgresql-common).
16
Анализ журнала
Средства операционной системы
grep, awk...
Специальные средства анализа
pgBadger — требует определенных настроек журнала
Анализировать журналы можно по-разному.
Можно искать определенную информацию средствами ОС или
специально разработанными скриптами.
Стандартом де-факто для анализа является программа PgBadger
https://github.com/darold/pgbadger, но надо иметь в виду, что она
накладывает определенные ограничения на содержимое журнала. В
частности, допускаются сообщения только на английском языке.
18
Внешний мониторинг
Универсальные системы мониторинга
Zabbix, Munin, Cacti...
в облаке: Okmeter, NewRelic, Datadog...
Системы мониторинга PostgreSQL
pg_profile, pgpro_pwr
PGObserver
PostgreSQL Workload Analyzer (PoWA)
Open PostgreSQL Monitoring (OPM)
...
На практике требуется полноценная система мониторинга, которая
собирает различные метрики как с PostgreSQL, так и с операционной
системы, хранит историю этих метрик, отображает их в виде понятных
графиков, имеет средства оповещения при выходе определенных
метрик за установленные границы и т. д.
Собственно PostgreSQL не располагает такой системой; он только
предоставляет средства для получения информации о себе (которые
мы рассмотрели). Поэтому для полноценного мониторинга нужно
выбрать внешнюю систему. Таких систем существует довольно много.
Есть универсальные системы, имеющие плагины или агенты для
PostgreSQL. К ним относятся Zabbix, Munin, Cacti, облачные сервисы
Okmeter, NewRelic, Datadog и другие.
Есть и системы, ориентированные специально на PostgreSQL, такие,
как PGObserver, PoWA, OPM и т. д. Расширение pg_profile позволяет
строить снимки статических данных и сравнивать их, выявляя
ресурсоемкие операции и их динамику. Расширенная коммерческая
версия этого расширения — pgpro_pwr.
Неполный, но представительный список систем мониторинга можно
посмотреть на странице https://wiki.postgresql.org/wiki/Monitoring
Для более глубокого погружения в эту тему можно прочитать книгу
Алексея Лесовского «Мониторинг PostgreSQL»:
19
Итоги
Мониторинг заключается в контроле работы сервера
как со стороны операционной системы,
так и со стороны самого сервера
PostgreSQL предоставляет накопительную статистику
и журнал сообщений сервера
Для полноценного мониторинга требуется внешняя система
20
Практика
1. В новой базе данных создайте таблицу, выполните вставку
нескольких строк, а затем удалите все строки.
Посмотрите статистику обращений к таблице и сопоставьте
цифры (n_tup_ins, n_tup_del, n_live_tup, n_dead_tup)
с вашей активностью.
Выполните очистку (vacuum), снова проверьте статистику
и сравните с предыдущими цифрами.
2. Создайте ситуацию взаимоблокировки двух транзакций.
Посмотрите, какая информация записывается при этом
в журнал сообщений сервера.
2. Взаимоблокировка (deadlock) — ситуация, в которой две (или
больше) транзакций ожидают друг друга. В отличие от обычной
блокировки при взаимоблокировке у транзакций нет возможности выйти
из этого «тупика» и СУБД вынуждена принимать меры — одна из
транзакций будет принудительно прервана, чтобы остальные могли
продолжить выполнение.
Проще всего воспроизвести взаимоблокировку на таблице с двумя
строками. Первая транзакция меняет (и, соответственно, блокирует)
первую строку, а вторая — вторую. Затем первая транзакция пытается
изменить вторую строку и «повисает» на блокировке. А потом вторая
транзакция пытается изменить первую строку — и тоже ждет
освобождения блокировки.
21
Практика+
1. Установите расширение pg_stat_statements.
Выполните несколько произвольных запросов.
Посмотрите, какую информацию показывает представление
pg_stat_statements.
1. Для установки расширения потребуется перед выполнением команды
CREATE EXTENSION изменить значение параметра
shared_preload_libraries с последующей перезагрузкой сервера.
