Задачи администрирования
Мониторинг
16
Авторские права
© Postgres Professional, 2017–2024
Авторы: Егор Рогов, Павел Лузанов, Илья Баштанов, Алексей Береснев
Фото: Олег Бартунов (монастырь Пху и пик Бхрикути, Непал)
Использование материалов курса
Некоммерческое использование материалов курса (презентации,
демонстрации) разрешается без ограничений. Коммерческое
использование возможно только с письменного разрешения компании
Postgres Professional. Запрещается внесение изменений в материалы
курса.
Обратная связь
Отзывы, замечания и предложения направляйте по адресу:
Отказ от ответственности
Компания 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).
Если используются дисковые квоты, надо принимать во внимание и их.
В целом набор инструментов и подходы может сильно различаться
в зависимости от используемой ОС и файловой системы, поэтому
подробно здесь не рассматриваются.
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 с последующей перезагрузкой сервера.
