Описание
Для получения и отображения метрик PostgreSQL используется комплексное решение pgwatch2, которое имеет встроенный экспортер метрик, БД для хранения метрик и собственный экземпляр Grafana с заранее созданными дашбордами. Официальная документация.
Установка
См. v0.7_7.2 Мониторинг состояния сервисов.
Для предварительной подготовки БД к мониторингу необходимо выполнить ряд действий, которые описаны в официальной документации. Если Postgresql установлен как сервис (не в docker), то эти действия можно выполнить автоматически, запустив вышеописанный ansible-плейбук с тегом prepare-postgres. Если PostgreSQL планируется запускать в docker, то необходимо использовать специальный docker image, где эта подготовка выполнена. Этот image поставляется вместе с другими компонентами NAICE.
Предварительная настройка
После установки pgwatch2 необходимо выполнить предварительную настройку, указав данные для доступа к БД, полноту сбора метрик и некоторые другие параметры. Настройка выполняется на отдельной web-странице, доступной по адресу http://<IP-адрес pgwatch2>:<web-порт pgwatch2> (порт по-умолчанию при установке ansible-плейбуком - 9080). Документация на Admin Web UI.
Необходимо создать новое подключение и указать следующие его параметры (таблица проматывается вправо по ползунку под ней!):
- имя (unique name) - произвольное имя, под которым БД будет отображаться в Grafana;
- тип БД (DB type) - postgres;
- адрес хоста с БД (DB host);
- порт, по которому доступна БД на хосте (DB port);
- пользователь БД для мониторинга (DB user) - пользователь по умолчанию - pgwatch2;
- пароль пользователя БД для мониторинга (DB password) - пароль по умолчанию - secret;
- конфигурация метрик (preset metrics config, standby preset config) - full;
- включение (enabled) - true.
После указания всех параметров не забудьте сохранить настройки по кнопке Save.
Дашборды Grafana
Для получения доступа к дашборду Grafana откройте браузер и перейдите по адресу http://<IP-адрес хоста мониторинга>:<порт Crafana для pgwatch2>. Номер порта, на котором работает встроенная в pgwatch2 Grafana, задается во время установки сервиса, по умолчанию - 3001.
По умолчанию при входе логин и пароль не требуются, но после деавторизации и повторного входа данные потребуются. Логин и пароль пользователя по умолчанию - pgwatch2 / pgwatch2admin.
При входе в Grafana на начальной странице отображается дашборд Helth-check. Для проверки корректности настроек убедитесь что данные в информационных панелях присутствуют.
Описание панелей дашбордов
| Панель | Пояснение |
|---|---|
Health-check | |
| All | Агрегирует в себе наиболее важные показатели других дашбордов. По нему можно примерно оценить текущее состояние БД. Для более тщательной оценки необходимо смотреть дашборды на конкретную группу показателей |
Alert Template | |
| 1 active primary per cluster | Количество активных мастеров primary в кластере. Всегда должен быть 1 primary в кластере! Если 0 - упал primary и данные не пишутся в БД. Нужно поднимать primary. Если > 1 - необходимо разобраться, почему внезапно replica стала primary и приводить кластер к 1 primary. |
| Instance connection used % | Процент коннектов к базе относительно максимального числа коннектов. При достижении 100% новые коннекты к БД перестают создаваться. Нужно выяснять, кто занял все коннекты (pg_stat_activity). Не должен превышать 50%. |
| Inactive replication slots | Число неактивных слотов репликации. Должен быть 0. Если > 0 - одна из replica не может подключиться. |
| Waiting sessions > 10 | Число коннектов к БД со статусом ожидаемого типа события wait_event_type: LWLock или Lock или BufferPin. Появление таких коннектов указывает на блокировки в БД. В pg_stat_activity нужно смотреть wait_event, чтобы узнать имя ожидаемого события, из-за которого произошла блокировка. |
Checkpointer / Bgwriter / Block IO Stats | |
| Checkpoints | Агрегированное по времени количество запланированных (timed) и вызванных (req) чекпоинтов. В идеале checkpoints_req должен быть равен 0 или сильно меньше checkpoints_timed. Если checkpoints_req очень много, нужно смотреть скорость записи WAL и max_wal_size. checkpoints_timed регулируется checkpoint_timeout. |
| Checkpointer Write / Sync duration | checkpoint_write_time - общее время, которое было затрачено на этап обработки контрольной точки, в котором файлы записываются на диск checkpoint_sync_time - общее время, которое было затрачено на этап обработки контрольной точки, в котором файлы синхронизируются с диском |
| Bgwriter Stats | buffers_checkpoint - Количество буферов, записанных при выполнении контрольных точек buffers_clean - Количество буферов, записанных фоновым процессом записи buffers_backend - Количество буферов, записанных самим серверным процессом |
| Table / Index / Toast Blocks Read | heap_blks_read - Количество дисковых блоков, прочитанных из этой таблицы idx_blks_read - Количество дисковых блоков, прочитанных из всех индексов этой таблицы toast_blks_read - Количество прочитанных дисковых блоков TOAST (если есть) для этой таблицы tidx_blks_read - Количество прочитанных дисковых блоков из индекса по TOAST (если есть) для этой таблицы |
DB overview Unprivileged | |
| Instance State | Статус сервера: Primary или Replica |
| Instance Uptime | Uptime |
| TPS | Transaction Per Second - количество наборов запросов к БД в секунду, которые должны полностью успешно завершиться с commit, иначе все запросы в наборе откатываются. |
| QPS | Query Per Second - количество запросов в секунду. |
| Query Runtime | Среднее время выполнения запроса. |
| DB size change 1h | Изменение размера базы данных за час. |
| Approx Table Bloat | Средний размер таблиц. |
| Tuples fetched vs returned | Процент строк, затронутых запросами, которые фактически возвращаются клиенту. Низкие значения (<10%) для рабочей нагрузки OLTP могут указывать на отсутствующие индексы |
| Tuples insert/delete/update statistics | Статистика по записанным, удаленным и обновленным строкам. Лучше смотреть в масштабе длительного времени |
| Shared Buffers Hit Ratio + Rollback Ratio | Процент блоков, прочитанных из кэша от общего числа прочитанных блоков. Должен быть > 90% Процент транзакций, для которых был выполнен откат |
| Avg. query runtime | Среднее время выполнения запроса. Нормальное значение в районе мс, если приближается к минуте - тревожный звонок. |
| WAL rate + DB size | |
Session + Deadlocks | |
TPS/QPS | Отображает во времени количество транзаций и запросов в секунду. Пики говорят об увеличении нагрузки на БД в данный промежуток времени. |
| Seq. scans | |
| Exclusive Locs | |
Global DB overview | |
| TPS | |
| QPS | |
| Query Runtime | |
| Total DB size change | |
| Total table bloat change | |
| CPU Load Average | |
| Tx error ratio | |
| Db size | Размер БД во времени |
| CPU Load | |
| Temp bytes written | |
| WAL rate | Скорость записи в WAL-файлы. Должно соответствовать настроенному max_wal_size чтобы файлы не заполнялись слишком быстро (хотя бы не больше чем за 5 минут) и слишком часто не происходило чекпоинтов (сохранение данных из оперативной памяти). Все оперативные данные из RAM дублируется в WAL-файлы для избегания потерь данных при внезапном ребуте сервера. |
| Shared buffers hit ratio | |
| Non-idle sessions | Показываются активные коннекты, то есть коннекты в которых выполняются какие-либо действия и которые используют ресурсы CPU. В идеале количество активных коннектов не должно превышать количество CPU на сервере. Если их на порядок больше, то возможно каждый CPU не будет успевать обрабатывать каждый коннект. |
Index Overview | |
Lock Details | |
| Locking details | Статистика появления блокировок различного типа. Все кроме AccessShareLock (доступ к ресурсу блокируется не полностью) представляют опасность |
Session Overview | |
| Max. TPS/QPS | Количество транзакций и запросов в секунду во времени для конкретной БД |
| Longest query duration | |
| Longest wait duration | Наибольшее время ожидания завершения коннектов в состоянии waiting, то есть коннектов ждущих разблокировки ресурса для выполнения транзакций. |
| Longest TX duration | |
| Longest session duration | |
| Longest Autovacuum duration / AV Workers | Длительность самого последнего автоматического процесса VACUUM (> часа - должно настораживать) Причина почему может увеличиться время - автовакуум использует при сканировании таблиц не index scan, а seq scan, нужно смотреть соответствующие метрики. |
| Session by state | Показывает во времени количество открытых коннектов к данной БД по типам коннектов (active, idle, idle-in-transaction и т.п.) Коннект idle-in-transaction - коннект, который для завершения выполнения транзакции находится в процессе выполнения каких-либо других действий. Такие коннекты блокируют таблицы, с которыми работают, для того чтобы не возникали коллизии, другие коннекты не могут работать с заблокированными данными. Если idle-in-transaction много и/или их количество увеличивается со временем, то нужно с ними разбираться. |
| Instance total connections | Показывает во времени максимальное количество коннектов к БД и текущее количество коннектов |
Single Query Details | |
| Avg. runtime | |
| Calls | |
| Total runtime | |
| Shared buffer hit ratio | |
| Temp Blocks Read/Written | |
| Backend block Read/Write time | |
| % of total_time spent in direct IO | |
| SQL | |
Stat statements Top | |
| Top queries by Total Runtime | Топ запросов по длительности выполнения всех запросов (время * количество), более показателен чем среднее время запуска одного запроса |
| Top queries by Avg Runtime | Топ запросов с самым высоким средним временем выполнения (total / количество) |
| Top queries by calls | Топ самых вызываемых запросов |
| Top queries by direct (backend) Io | |
| Top by block bandwidth | |
Stat statements Top (Visual) | |
| Top 5 queries by calls | |
| Top 5 queries by total time | |
System stats | |
Table Details | |
| Size | Рост в динамике количества данных в таблице. |
| Scans | |
| IUD | |
| Shared Buffers hit rates | Показывает, какой процент из прочитанных данных был взят из кэша. Скорость чтения данных с кэша выше чем с диска, поэтому чем ближе к 100% тем лучше (обратить внимание если < 90%). |
| Index Scans per index | Чем больше index scan по отношению к seq scan, тем лучше, так как индексы работают быстрее |
| Time since last VACUUM | Время с последнего VACUUM, он не должен происходить редко (> суток - должно настораживать) При удалении данных из таблицы они не удаляются, а просто помечаются к удалению. За реальное удаление отвечает процесс вакуума - периодический процесс, который находит объекты для чистки (> 20% строк таблицы помечены для удаления). Есть несколько видов вакуума. Полное удаление с очисткой места для ОС (vacuum full) происходит полным копированием таблицы без удаленных строк и удаляется изначальная таблица. Если таблица занимает больше половины диска, то она не сможет скопироваться заполнив диск на 100%. |
| Time since last ANALYZE | |
Tables Top | |
| Biggest (total) | |
| Biggest (data) | |
| Biggest growth (total relation size) | |
| Most "seq. scans" | |
| Most INSERT-s | |
| Most UPDATE-s | |
| Most DELETE-s | |
| most block IO reads | |