Это цитата одного из моих знакомых который когда-то давно обращался ко мне с вопросом про Postgres. Тогда мы за пару дней порешали его проблему и поблагодарив меня он добавил: "Хорошо, когда есть знакомый DBA".
Но что делать если нет знакомого DBA? Вариантов ответа может быть довольно много, начиная от поискать среди друзей друзей и заканчивая до изучить вопрос самостоятельно. Но какой бы ответ не пришел к вам в голову, у меня для вас хорошая новость. В тестовом режиме мы запустили сервис рекомендаций для Postgres и всего что вокруг него. Что это такое и как мы докатились до жизни такой
Зачем это всё?
Postgres это как минимум не просто, а иногда и очень сложно. Зависит от степени вовлеченности и ответственности.
Тем кто в operations нужно следить за тем чтоб Postgres как сервис работал исправно и стабильно - следить за утилизацией ресурсов, за доступностью, за адекватностью конфигурации, периодически проводить обновления и регулярные проверки здоровья. Тем кто в разработке и пишет приложения, в общих чертах нужно следить за тем как приложение взаимодействует с базой и что оно не создает аварийных ситуаций которые могли бы обрушить базу. Если человеку не повезло настолько что он техлид/техдир, то ему важно чтобы Postgres в целом работал надежно, предсказуемо и не создавал проблем, при это желательно самому не погружаться в Postgres глубоко и надолго.
В любом из этих случаев есть ты и Postgres. Чтобы хорошо обслуживать Postgres в нем нужно неплохо разбираться и представлять как он устроен. Если Postgres не является прямой специализацией, то на его изучение можно потратить довольно много времени. В идеальном случае когда есть время и желание, то не всегда понятно с чего начать, как и куда двигаться.
Даже если обложиться мониторингом, который по идее должен облегчить эксплуатацию, вопрос экспертных знаний остается открытым. Чтобы уметь читать и понимать графики нужно все также иметь хорошее представление о том как устроен Postgres. В противном случае любой мониторинг превращается в невеселые картинки и спам от алертов в случайное время суток.
Weaponry как раз сделан для того, чтобы облегчить эксплуатацию Postgres. Сервис собирает и анализирует данные о Postgres'е и дает рекомендации о том что можно улучшить.
Основная цель сервиса это давать понятные рекомендации, которые дают представление о том что происходит и что нужно делать дальше.
Для специалистов у которых нет экспертных знаний, рекомендации дают отправную точку для повышения квалификации. Продвинутым специалистам рекомендации указывают на те моменты на которые следует обратить внимание. В этом плане Weaponry выступает в роли помощника который выполняет рутинные задачи по поиску проблем или недостатков и требуют отдельного внимания. Weaponry можно сравнить с линтером который проверяет Postgres и указывает на недостатки.
Как обстоят дела сейчас
На данный момент Weaponry находится в тестовом режиме и на бесплатной основе, регистрация пока временно ограничена. Совместно с несколькими добровольцами допиливаем движок рекомендаций на около-боевых базах, выявляем ложные срабатывания и работаем над текстом рекомендаций.
К слову рекомендации пока довольно прямолинейные - просто говорят что и как делать, без дополнительных подробностей - так что первое время придется переходить по сопутствующим ссылкам, либо догугливать. Проверки и рекомендации охватывают настройки системы и оборудования, настройки самого 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 сервис.
На этом установка заканчивается. В течение пары минут инстанс БД появится в списке хостов в интерфейсе и можно уже смотреть первые рекомендации. Но важный момент, многие рекомендации требуют большого количества накопленных метрик (хотя бы за сутки).
Ru6aKa
По описанию из статьи ничего не понятно.
На сайте ноль полезной информации.
В демке тоже ничего не ясно.
Зато уже существует раздел «Pricing».
lesovsky Автор
Я постарался как раз таки не перегружать статью нудными и длинными описаниями. Вот про Pricing хорошее замечание, там надо будет написать про тестовый режим.
Ru6aKa
Статья получилась перегружена маркетингом.
Минимальный блок «интеграция с существующей базой» снял бы 90% вопросов.
lesovsky Автор
Да уж какой тут маркетинг? Тут в посте всего две мысли «мы сделали тулзу для проверки постгресов» и «ищем добровольцев» )))
Согласен, если мне это кажется очевидным моментом, то для нового пользователя это конечно не так. Мне кажется все сервисы пытаются сделать интеграцию как можно проще, в 1-2-3 клика/команды и плюс стартовая страница с инструкцией. В нашем случае все точно также, в самом простом варианте одной командой скачивается агент и через пайп запускается его установка. В демке кстати есть страница с описанием установки.
Еще раз спасибо за фидбек.
Ru6aKa
В вашем кейсе процесс интеграции (установка, настройка агента) должен быть описан в статье, в документации на сайте, в каком-то хелпе в демке, а так же присутствовать в виде видео-инструкции. В вашем случае работает правило «Нет агента — нет клиента».
lesovsky Автор
Понял, принял, исправлюсь.
Ru6aKa
Про устройство агента тоже можно было бы рассказать. На чем написан, какие метрики собирает, можно ли настраивать кастомные метрики, есть ли офлайн режим работы, есть ли алерты, анализирует ли этот агент запросы.
lesovsky Автор
Агент написан на Go, умеет собирать системные метрики, метрики постгреса и баунсера.
Кастомных метрик и оффлайн режима пока нет, эти фичи планировалось добаивть в случае открытия кода агента (когда внутреннее апи агента стабилизируется). Алертов нет, т.к. это не задача агента. По запросам собираются только метрики на основе pg_stat_statements, более глубого анализа запросов пока нет (есть возможность отключения трекинга текстов запросов чтобы не слать их в наш сервис, вместо текстов будут queryid). Код агента в перспективе планируется открыть, но пока не до этого.
Вообще конечно вы мне дали массу набросков на еще одну статью)))
Ru6aKa
С алертами не соглашусь, если ваш агент собирает системные метрики такие как использование диска и памяти, то логично что пользователь захочет алерты по этим метрикам. Ну не ставить же рядом забикс для мониторинга одной машины с постргесом. Если для онлайн режима алерт шлет ваш сервер, то для офлайн режима логично чтобы это делал сам агент.
Мне нравиться подход atop, пишем все в логи, потом можем просматривать туда/сюда в консоле.
Мне почему-то кажется что такой же подход должен быть и у вас. Один агент собирает все в файлы, второй агент шлет все это на сервер для дальнейшего анализа, третий агент отвечает чисто за алерты всякие(если сеть доступна то шлем алерт на сервер, который дальше шлет сообщение в телегу/вайбер/ватсап/зум, если сети нет — то алерт по тому что настроил клиент). Консольный клиент для просмотре того что попало в логи, без аналитики. Все что через веб с аналитикой. Соответственно консоль с минимумом функций и простым алертом — бесплатный тариф. Веб с аналитикой и разными видами алертов — уже платный тариф.
lesovsky Автор
> Если для онлайн режима алерт шлет ваш сервер, то для офлайн режима логично чтобы это делал сам агент.
Боюсь что это сильно усложнит настройку агента для пользователя (как минимум надо указывать тип нотификации и реквизиты куда их отправлять). Установка агента же должна быть простой как палка. Но как доп. фича — почему бы и нет.
Описанный вами вариант с множеством агентов напоминает мне связку prometheus, alertmanager плюс экспортеры на любой вкус. Это подходящий вариант когда есть задача сделать мониторинг уровня инфраструктуры. Но в случае saas мониторингов для агентов важен подход быстро запустить и начать сбор/отправку метрик.
Еще добавлю про системные метрики — их сбор нужен потому что рассматривать администрирование постгреса в отрыве от системы просто невозможно. Поэтому сервису нужен весь «комплект» — метрики системы и постгреса. Сбор метрик с агента системами клиента кстати заложен в архитектуру агента. Но пока непонятно насколько оно надо.