Eltex Documentation
Дерево страниц
Перейти к концу метаданных
Переход к началу метаданных


Описание

Для получения и отображения метрик PostgreSQL используется комплексное решение pgwatch2, которое имеет встроенный экспортер метрик, БД для хранения метрик и собственный экземпляр Grafana с заранее созданными дашбордами. Официальная документация.


Установка

См. Мониторинг NAICE - Установка.

Для предварительной подготовки БД к мониторингу необходимо выполнить ряд действий, которые описаны в официальной документации. Если 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 UptimeUptime
TPSTransaction Per Second - количество наборов запросов к БД в секунду, которые должны полностью успешно завершиться с commit, иначе все запросы в наборе откатываются.
QPSQuery 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
  • Нет меток