Це цитата одного з моїх знайомих, який колись давно звертався до мене з питанням про Postgres. Тоді ми за пару днів вирішили його проблему і, подякувавши мені, він додав: «Добре, коли є знайомий DBA».
Але що робити, якщо немає знайомого DBA? Варіантів відповіді може бути досить багато, починаючи від пошукати серед друзів друзів і до вивчити питання самостійно. Але яка б відповідь не спала на вас, у мене для вас хороша новина. У тестовому режимі ми запустили сервіс рекомендацій для Postgres і всього навколо нього. Що це таке і як ми докотилися до такого життя
Навіщо це все?
Postgres це, як мінімум, не просто, а іноді і дуже складно. Залежить від ступеня залучення та відповідальності.
Тим хто в operations необхідно стежити за тим, щоб Postgres як сервіс працював справно і стабільно - стежити за утилізацією ресурсів, за доступністю, за адекватністю зміни, періодично проводити оновлення та регулярні перевірки здоров'я. Тим хто у розробці і пише додатки, загалом слід стежити, як додаток взаємодіє з базою і що вона створює аварійних ситуацій які б обрушити базу. Якщо людині не пощастило настільки, що він техлід/техдир, то йому важливо, щоб Postgres в цілому працював надійно, передбачувано і не створював проблем, при цьому бажано самому не занурюватися в Postgres глибоко і надовго.
У будь-якому з цих випадків є ти та Postgres. Щоб добре обслуговувати Postgres у ньому потрібно непогано розбиратися та уявляти як він влаштований. Якщо Postgres не є прямою спеціалізацією, то на його вивчення можна витратити чимало часу. В ідеальному випадку, коли є час і бажання, то не завжди зрозуміло з чого почати, як і куди рухатися.
Навіть якщо обкластися моніторингом, який, за ідеєю, повинен полегшити експлуатацію, питання експертних знань залишається відкритим. Щоб вміти читати і розуміти графіки потрібно мати хороше уявлення про те, як влаштований Postgres. В іншому випадку будь-який моніторинг перетворюється на невеселі картинки та спам від алертів у випадковий час доби.
Основна мета сервісу це давати зрозумілі рекомендації, які дають уявлення про те, що відбувається і що потрібно робити далі.
Для фахівців, які не мають експертних знань, рекомендації дають відправну точку для підвищення кваліфікації. Просунутим спеціалістам рекомендації вказують на ті моменти, на які слід звернути увагу. У цьому плані Weaponry виступає в ролі помічника, який виконує рутинні завдання з пошуку проблем або недоліків і вимагають окремої уваги. Weaponry можна порівняти з лінтером, який перевіряє Postgres і вказує на недоліки.
Як справи зараз
На даний момент
До речі рекомендації поки що досить прямолінійні - просто говорять що і як робити, без додаткових подробиць - так що спочатку доведеться переходити за супутніми посиланнями, або догуглювати. Перевірки та рекомендації охоплюють налаштування системи та обладнання, налаштування самого Postgres, схему всередині, використовувані ресурси. У планах ще досить багато речей, які потрібно додати.
Ну і звичайно ми знаходимося в пошуку добровольців, які готові спробувати сервіс і дати зворотний зв'язок. Ще у нас є
Updated 2020-09-16. Getting started.
Після реєстрації користувачеві пропонується створити проект, який дозволяє об'єднувати інстанси БД у групи. Після створення проекту користувач направляється в інструкцію з налаштування та встановлення агента. Якщо двома словами, то потрібно створити користувачів для агента, після чого завантажити скрипт установки агента і запустити його. У shell командах це виглядає приблизно так:
psql -c "CREATE ROLE pgscv WITH LOGIN SUPERUSER PASSWORD 'A7H8Wz6XFMh21pwA'"
export PGSCV_PG_PASSWORD=A7H8Wz6XFMh21pwA
curl -s https://dist.weaponry.io/pgscv/install.sh |sudo -E sh -s - 1 6ada7a04-a798-4415-9427-da23f72c14a5
Якщо на хості є pgbouncer, то для підключення агента також потрібно створити користувача. Конкретний метод налаштування користувача в pgbouncer може бути дуже варіативним і залежить від використовуваної конфігурації. Загалом налаштування зводиться до додавання користувача в stats_users файлу конфігурації (зазвичай це pgbouncer.ini) та прописуванні пароля (або його хеша) у файл вказаний у параметрі auth_file. При зміні stats_users знадобиться рестарт pgbouncer.
Скрипт install.sh приймає кілька обов'язкових аргументів, які унікальні для кожного проекту, і через змінні оточення приймає реквізити створених користувачів. Далі скрипт запускає агента в режимі bootstrap - агент копіює себе в PATH, створює конфіг з реквізитами, systemd юніт і запускається як systemd сервіс.
У цьому установка закінчується. Протягом кількох хвилин інстанс БД з'явиться у списку хостів в інтерфейсі і можна дивитися перші рекомендації. Але важливий момент, багато рекомендацій вимагають великої кількості накопичених метрик (хоча б за добу).
Джерело: habr.com