1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/mirrors-postgres-checkup

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
README.md

Поддержка проекта: поставьте GitLab звезду (на главной странице https://gitlab.com/postgres-ai/postgres-checkup/, в правом верхнем углу):

Добавьте звезду

Демо: пример отчёта postgres-checkup (https://gitlab.com/postgres-ai/postgres-checkup-tests/tree/master/1.3.0) (основан на CI, многоузловой).

Отказ от ответственности: выводы и рекомендации — работа в процессе.

Для корректной обработки данных требуются глубокие знания Postgres. Каждый отчёт состоит из трёх разделов: наблюдения, выводы и рекомендации. Наблюдения заполняются автоматически. Что касается разделов «Выводы» и «Рекомендации», не все отчёты создаются автоматически.

О проекте

Postgres Checkup (postgres-checkup) — это новый инструмент диагностики для глубокого анализа состояния базы данных Postgres. Он выявляет текущие и потенциальные проблемы с производительностью, масштабируемостью и безопасностью базы данных. Также он выдаёт рекомендации по их устранению или предотвращению.

Система мониторинга покажет только текущие, неотложные проблемы. А postgres-checkup выявит скрытые, более глубокие проблемы, которые могут возникнуть в будущем. Инструмент помогает решить многие известные проблемы администрирования баз данных и распространённые ошибки. Его цель — обнаруживать проблемы на очень ранней стадии и предлагать наилучшие способы их предотвращения. Мы рекомендуем запускать его регулярно — еженедельно, ежемесячно и ежеквартально. А также перед и после внесения любых серьёзных изменений в сервер базы данных, будь то схема, параметры конфигурации или настройки кластера.

Зачем нужен postgres-checkup и почему он безопасен и прост в использовании:

  • Он ненавязчив: его влияние на наблюдаемую систему практически равно нулю. Он не использует тяжёлые запросы, что позволяет использовать ресурсы очень экономно и избежать «эффекта наблюдателя». Отчёты postgres-checkup успешно протестированы на реальных базах данных, содержащих более 500 000 таблиц и более 1 000 000 индексов.

  • Установка не требуется (на наблюдаемых машинах): он может анализировать любую машину Linux (включая виртуальные машины), а также облачные экземпляры Postgres (например, Amazon RDS или Google Cloud SQL), не требуя дополнительной настройки или изменений. Однако ему требуется привилегированный доступ, который обычно есть у администратора баз данных (DBA).

  • Комплексный анализ: в отличие от большинства инструментов мониторинга, которые предоставляют только необработанные данные, postgres-checkup объединяет данные из разных частей системы (например, внутренняя статистика Postgres сочетается со знаниями о системных ресурсах в настройках автоочистки и анализе поведения), объединяя данные в хорошо структурированные отчёты, направленные на решение конкретных проблем администратора баз данных. Кроме того, он анализирует главный сервер базы данных вместе со всеми его репликами, что необходимо в таких случаях, как анализ индекса или поиск отклонений в настройках.

Структура отчётов

Postgres-checkup создаёт два вида отчётов для каждой проверки:

  • Отчёты в формате JSON (*.json) — могут использоваться любой программой или сервисом или храниться в какой-либо базе данных.

  • Отчёты в формате Markdown (*.md) — основной формат для людей, могут содержать списки, таблицы, изображения. Являясь родным форматом для GitLab и GitHub, такие отчёты готовы к использованию, например, в их системах отслеживания задач, упрощая рабочий процесс. Отчёты Markdown выводятся из отчётов JSON.

Отчёты Markdown можно преобразовать в другие форматы, такие как HTML или PDF.

Каждый отчёт состоит из трех разделов:

  1. «Наблюдения»: автоматически собранные данные. Они предназначены для экспертов DBA.
  2. «Выводы»: что мы заключаем из наблюдений, изложено простым языком в форме, удобной для инженеров, не являющихся экспертами DBA.
  3. «Рекомендации»: действия, что нужно сделать, чтобы устранить обнаруженные проблемы.

И «Выводы», и «Рекомендации» предназначены для инженеров, которые будут принимать решения о том, что, как и когда оптимизировать.

Установка и использование

Требования

На машине оператора (откуда будет запускаться инструмент) поддерживаются следующие ОС:

  • Linux (современные версии). RHЕL/CentOS или Debian/Ubuntu (должны работать и другие, но они ещё не протестированы);
  • MacOS.

Известны случаи успешного использования postgres-checkup на Windows, хотя и с некоторыми ограничениями.

На компьютере оператора должны быть установлены следующие программы:

  • bash;
  • psql;
  • coreutils;
  • jq >= 1.5;
  • go >= 1.17 (на данный момент бинарные файлы не поставляются);
  • awk;
  • sed;
  • pandoc *;
  • wkhtmltopdf >= 0.12.4 *.

Pandoc и wkhtmltopdf являются опциональными, они нужны для создания HTML и PDF версий отчёта (опции --html, --pdf).

Ничего особенного устанавливать на наблюдаемые машины не нужно. Однако они должны работать под управлением Linux (опять же: современные RHЕL/CentOS или Debian/Ubuntu; другие тоже должны работать, но ещё не проверены).

:warning: В настоящее время официально поддерживается только Postgres версии 9.6 и выше.

Как установить

1. Установите необходимые программы

Ubuntu/Debian:

sudo apt-get update -y
sudo apt-get install -y git postgresql coreutils jq golang

# Опционально (для создания отчётов в формате PDF/HTML)
sudo apt-get install -y pandoc
wget https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.4/wkhtmltox-0.12.4_linux-generic-amd64.tar.xz
tar xvf wkhtmltox-0.12.4_linux-generic-amd64.tar.xz
sudo mv wkhtmltox/bin/wkhtmlto* /usr/local/bin
sudo apt-get install -y openssl libssl-dev libxrender-dev libx11-dev libxext-dev libfontconfig1-dev libfreetype6-dev fontconfig

CentOS/RHEL:

sudo yum install -y git postgresql coreutils jq golang

# Опционально (для создания отчётов в формате PDF/HTML)
sudo yum install -y pandoc
wget https://github.com/wkhtmltopdf/wkhtmltopdf/releases/download/0.12.4/wkhtmltox-0.12.4_linux-generic-amd64.tar.xz
tar xvf wkhtmltox-0.12.4_linux-generic-amd64.tar.xz
sudo mv wkhtmltox/bin/wkhtmlto* /usr/local/bin
sudo yum install -y libpng libjpeg openssl icu libX11 libXext libXrender xorg-x11-fonts-Type1 xorg-x11-fonts-75dpi

MacOS (при условии, что установлен Homebrew):

brew install postgresql coreutils jq golang git

# Опционально (для создания отчётов в формате PDF/HTML)
brew install pandoc Caskroom/cask/wkhtmltopdf

2. Клонируйте этот репозиторий

git clone https://gitlab.com/postgres-ai/postgres-checkup.git
# Используйте --branch для использования конкретной версии выпуска. Например, чтобы использовать версию 1.1:
#   git clone --branch 1.1 https://gitlab.com/postgres-ai/postgres-checkup.git
cd postgres-checkup

3. Соберите pghrep

cd ./pghrep
make main
cd ..

Пример использования

Давайте создадим отчёт для проекта с именем prod1. Предположим, у нас есть два сервера, db1.vpn.local и db2.vpn.local.

Postgres-checkup автоматически определяет, какой из них является главным:

./checkup -h db1.vpn.local -p 5432 --username postgres --dbname postgres --project prod1 -e 1
./checkup -h db2.vpn.local -p 5432 --username postgres --dbname postgres --project prod1 -e 1

Что буквально означает: подключиться к серверу с заданными учётными данными, сохранить данные в каталог проекта prod1, как эпоху проверки 1. Эпоха — это числовое (целое) обозначение текущей итерации. Например: через полгода мы можем перейти на «эпоху номер 2».

-h db2.vpn.local означает: попытаться подключиться к хосту через SSH, а затем использовать удалённую команду psql для выполнения проверок. Если SSH недоступен, будет использоваться локальный psql (отчёты без использования psql будут пропущены) для установления соединения с PostgreSQL. Если вы хотите избежать «угадывания», используйте -ssh-hostname или --pg-hostname.

Также можно определить конкретный способ подключения: SSH или psql:

--ssh-hostname db2.vpn.local — будет использован SSH для подключения. Порт SSH также можно задать с помощью опции --ssh-port.

--pg-hostname db2.vpn.local — для подключения будет использоваться psql. Порт, на котором PostgreSQL принимает соединения, можно задать с помощью параметра --pg-port.

В случае, когда --pg-port или --ssh-port не определены, но --port определён, значение параметра --port будет использовано вместо --pg-port или --ssh-port, в зависимости от текущего типа подключения.

Для всестороннего анализа рекомендуется запустить инструмент на главном сервере и всех его репликах. postgres-checkup способен объединить всю информацию с нескольких узлов в единый отчёт.

Некоторые отчёты (например, K003) требуют двух снимков для расчёта «дельт» показателей. Поэтому для получения более точных результатов используйте следующий пример, выполняя его в часы пиковой нагрузки с значениями $DISTANCE от 10 минут до нескольких часов:

$DISTANCE="1800" # 30 минут

# Предполагая, что db2 является главным, а db3 и db4 — его репликами
for host in db2.vpn.local db3.vpn.local db4.vpn.local; do
  ./checkup \
    -h "$host" \
    -p 5432 \
    --username postgres \
    --dbname postgres \
    --project prod1 \
    -e 1 \
    --file resources/checks/K000_query_analysis.sh # первый снимок нужен только для отчётов K***
done

sleep "$DISTANCE"

for host in db2.vpn.local db3.vpn.local db4.vpn.local; do
  ./checkup \
    -h "$host" \
    -p 5432 \
    --username postgres \
    --dbname postgres \
    --project prod1 \
    -e 1
done

В результате выполнения будут созданы два каталога с файлами .json и .md:

./artifacts/prod1/json_reports/1_2018_12_06T14_12_36_+0300/
./artifacts/prod1/md_reports/1_2018_12_06T14_12_36_+0300/

Каждый из созданных файлов содержит информацию о том, «что мы проверяем», и собранные данные для всех экземпляров кластера postgres prod1.

Отчёт в удобном для чтения формате можно найти по адресу:

./artifacts/prod1/md_reports/1_2018_12_06T14_12_36_+0300/Full_report.md

Откройте его с помощью вашего любимого средства просмотра файлов Markdown или просто загрузите на такой сервис, как gist.github.com.

Можно собирать и обрабатывать данные отдельно, указав имя режима работы в параметре CLI --mode %mode% или используя его как «команду» (checkup %mode%). Доступные режимы работы:

  • collect — сбор данных;
  • process — генерация отчётов MD (и, опционально, HTML, PDF) с выводами и рекомендациями;
  • upload — загрузка сгенерированных отчётов на платформу Postgres.ai;
  • run — сбор и обработка данных одновременно. Это режим по умолчанию, он используется, если не указан другой режим. Обратите внимание, что загрузка не включена.

Docker 🐳

Возможно использование postgres-checkup из контейнера Docker. Контейнер будет запущен, выполнит все проверки и остановится сам. Результат проверки можно найти в папке artifacts текущего каталога (pwd).

Использование с docker run

Существует возможность запуска postgres-checkup в контейнере Docker:

docker run --rm \
  --name postgres-checkup \
  --env PGPASSWORD="postgres" \
  --volume `pwd`/artifacts:/checkup/artifacts \
  postgresai/postgres-checkup:latest \
    ./checkup \
      --hostname hostname \
      --port 5432 \
      --username postgres \
      --dbname postgres \
      --project c \
      --epoch "$(date +'%Y%m%d')001"

В этом случае некоторые проверки (требующие подключения по SSH) будут пропущены.

Если вы хотите получить все поддерживаемые проверки, вам необходимо использовать подключение по SSH к целевому компьютеру с базой данных Postgres.

При наличии соединения SSH с сервером Postgres можно передать ключи SSH в контейнер Docker, чтобы postgres-checkup переключился на работу через удалённые вызовы SSH, генерируя все отчёты (известно, что этот подход имеет проблемы в Windows, но должен хорошо работать на компьютерах с Linux и MacOS):

docker run --rm \
  --name postgres-checkup \
  --volume "$(pwd)/artifacts:/checkup/artifacts" \
  --volume "$(echo ~)/.ssh/id_rsa:/root/.ssh/id_rsa:ro" \
  postgresai/postgres-checkup:latest \
  ./checkup \
    --hostname sshusername@hostname \
    --username my_postgres_user \
    --dbname my_postgres_database \
    --project docker_test_with_ssh \
    --epoch "$(date +'%Y%m%d')001"

Если вы попытаетесь проверить локальный экземпляр postgres на своём хосте из контейнера, вы не сможете использовать localhost в параметре -h. Вам придётся использовать мост между хост-ОС и Docker Engine. По умолчанию IP-адрес хоста равен 172.17.0.1 в сети docker0, но он зависит от конфигурации. Более подробную информацию можно найти здесь.

Если вы используете SSH-соединение и sudo на хосте, то...

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

Постгре SQL: проверка работоспособности и анализ производительности SQL. Развернуть Свернуть
AGPL-3.0
Отмена

Обновления

Пока нет обновлений

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/mirrors-postgres-checkup.git
git@api.gitlife.ru:oschina-mirror/mirrors-postgres-checkup.git
oschina-mirror
mirrors-postgres-checkup
mirrors-postgres-checkup
master