Задачи администрирования
Мониторинг
13
Авторские права
© Postgres Professional, 2015‒2022
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания Postgres Professional не несет никакой ответственности за
любые повреждения и убытки, включая потерю дохода, нанесенные
прямым или непрямым, специальным или случайным использованием
материалов курса. Компания Postgres Professional не предоставляет
каких-либо гарантий на материалы курса. Материалы курса
предоставляются на основе принципа «как есть» и компания Postgres
Professional не обязана предоставлять сопровождение, поддержку,
обновления, расширения и изменения.
2
Темы
Средства операционной системы
Статистика внутри базы
Журнал сообщений сервера
Внешние системы мониторинга
3
Средства ОС
Процессы
ps (grep postgres)
параметр update_process_title для обновления статуса процессов
Использование ресурсов
iostat, vmstat, sar, top...
Дисковое пространство
df, du, quota...
PostgreSQL работает под управлением операционной системы и
в известной степени зависит от ее настроек.
Unix предоставляет множество инструментов для анализа состояния и
производительности.
В частности, можно посмотреть процессы, принадлежащие PostgreSQL.
Это особенно полезно при включенном (по умолчанию) параметре
сервера update_process_title, когда в имени процесса отображается его
текущее состояние.
Для изучения использования системных ресурсов (процессор, память,
диски) имеются различные инструменты: iostat, vmstat, sar, top и др.
Необходимо следить и за размером дискового пространства. Место,
занимаемое базой данных, можно смотреть как из самой БД (см.
модуль «Организация данных»), так из ОС (команда du). Размер
доступного дискового пространства надо смотреть в ОС (команда df).
Если используются дисковые квоты, надо принимать во внимание и их.
В целом набор инструментов и подходы может сильно различаться
в зависимости от используемой ОС и файловой системы, поэтому
подробно здесь не рассматриваются.
4
Статистика внутри базы
Процесс сбора статистики
Текущие активности системы
Отслеживание выполнения команд
Дополнительные расширения
Существует два основных источника информации о происходящем
в системе. Первый из них — статистическая информация, которая
собирается PostgreSQL и хранится внутри базы данных.
5
Сбор статистики
Настройки процесса stats collector
статистика параметр
обращения к таблицам и индексам track_counts
(доступы, затронутые строки) включен по умолчанию
и нужен для автоочистки
обращения к страницам track_io_timing
выключен по умолчанию
вызовы пользовательских функций track_functions
выключен по умолчанию
Кроме показа действий, непосредственно происходящих в данный
момент, PostgreSQL собирает и некоторую статистику.
Сбором статистики занимается фоновый процесс stats collector.
Количеством собираемой информации управляют несколько
параметров сервера, так как чем больше информации собирается, тем
больше и накладные расходы.
6
серверный
процесс
серверный
процесс
Архитектура
обслуживающий
процесс
stats collector
статистика
транзакции
агрегированная
статистика
между транзакциями
PGDATA/pg_stat_tmp/
PGDATA/pg_stat/
агрегированная
статистика
снимок
статистики
раз
в полсекунды
при первом
обращении
в транзакции
Каждый обслуживающий процесс собирает необходимую статистику
в рамках каждой выполняемой транзакции. Затем эта статистика
передается процессу-коллектору. Коллектор собирает и агрегирует
статистику со всех обслуживающих процессов. Раз в полсекунды
(время настраивается при компиляции) коллектор сбрасывает
статистику во временные файлы в каталог PGDATA/pg_stat_tmp.
(Поэтому перенесение этого каталога в файловую систему в памяти
может положительно сказаться на производительности.)
Когда обслуживающий процесс запрашивает информацию о статистике
(через представления или функции), в его память читается последняя
доступная версия статистики — это называется снимком статистики.
Если не попросить явно, снимок не будет перечитываться до конца
транзакции, чтобы обеспечить согласованность.
Таким образом, из-за задержек обслуживающий процесс получает не
самую свежую статистику — но обычно это и не требуется.
При останове сервера коллектор сбрасывает статистику в постоянные
файлы в каталог PGDATA/pg_stat. Таким образом, статистика
сохраняется при перезапуске сервера. Обнуление счетчиков
происходит по команде администратора, а также при восстановлении
сервера после сбоя.
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
Следить за ходом выполнения некоторых потенциально долгих команд
можно, выполняя запросы к соответствующим представлениям.
Структуры представлений описаны в документации:
Создание резервных копий рассматривается в модуле «Резервное
копирование».
В 14-й версии в этот список добавилось представление
pg_stat_progress_copy для отслеживания работы команды COPY.
11
Дополнительная статистика
Расширения в поставке
pg_stat_statements статистика по запросам
pgstattuple статистика по версиям строк
pg_buffercache состояние буферного кеша
Другие расширения
pg_wait_sampling статистика ожиданий
pg_stat_kcache статистика по процессору и вводу-выводу
pg_qualstats статистика по предикатам
…
Существуют расширения, позволяющие собирать дополнительную
статистику, как входящие в поставку, так и внешние.
Например, расширение pg_stat_statements сохраняет информацию
о запросах, выполняемых СУБД; pg_buffercache позволяет заглянуть
в содержимое буферного кеша и т. п.
12
Журнал сообщений
Настройка журнальных записей
Ротация файлов журнала
Анализ журнала
Второй важный источник информации о происходящем на сервере —
журнал сообщений.
13
Журнал сообщений
Приемник сообщений (log_destination = список)
stderr поток ошибок
csvlog формат CSV (только с коллектором)
syslog демон syslog
eventlog журнал событий Windows
Коллектор сообщений (logging_collector = on)
позволяет собирать дополнительную информацию
никогда не теряет сообщения (в отличие от syslog)
записывает stderr и csvlog в файл 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. А в 15-й версии для приемника
можно будет указать jsonlog.
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/dalibo/pgbadger, но надо иметь в виду, что она
накладывает определенные ограничения на содержимое журнала.
В частности, допускаются сообщения только на английском языке.
18
Внешний мониторинг
Универсальные системы мониторинга
Zabbix, Munin, Cacti...
в облаке: Okmeter, NewRelic, Datadog...
Системы мониторинга PostgreSQL
PGObserver
PostgreSQL Workload Analyzer (PoWA)
Open PostgreSQL Monitoring (OPM)
pg_profile, pgpro_pwr
...
На практике, если подходить к делу серьезно, требуется полноценная
система мониторинга, которая собирает различные метрики как
с PostgreSQL, так и с операционной системы, хранит историю этих
метрик, отображает их в виде понятных графиков, имеет средства
оповещения при выходе определенных метрик за установленные
границы и т. д.
Собственно PostgreSQL не располагает такой системой; он только
предоставляет средства для получения информации о себе (которые
мы рассмотрели). Поэтому для полноценного мониторинга нужно
выбрать внешнюю систему.
Таких систем существует довольно много. Есть универсальные
системы, имеющие плагины или агенты для PostgreSQL. К ним
относятся Zabbix, Munin, Cacti, облачные сервисы Okmeter, NewRelic,
Datadog и другие.
Есть и системы, ориентированные специально на PostgreSQL, такие,
как PGObserver, PoWA, OPM и т. д. Расширение pg_profile позволяет
строить снимки статических данных и сравнивать их, выявляя
ресурсоемкие операции и их динамику. Расширенная коммерческая
версия этого расширения — pgpro_pwr.
Неполный, но представительный список систем мониторинга можно
посмотреть на странице https://wiki.postgresql.org/wiki/Monitoring
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 с последующей перезагрузкой сервера.
