У нас там Postgres, но я хз что с ним делать (с)

    Это цитата одного из моих знакомых который когда-то давно обращался ко мне с вопросом про 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 сервис.
    На этом установка заканчивается. В течение пары минут инстанс БД появится в списке хостов в интерфейсе и можно уже смотреть первые рекомендации. Но важный момент, многие рекомендации требуют большого количества накопленных метрик (хотя бы за сутки).

    Комментарии 20

      +5
      По описанию из статьи ничего не понятно.
      На сайте ноль полезной информации.
      В демке тоже ничего не ясно.

      Зато уже существует раздел «Pricing».
        0
        Я постарался как раз таки не перегружать статью нудными и длинными описаниями. Вот про Pricing хорошее замечание, там надо будет написать про тестовый режим.
          0
          Статья получилась перегружена маркетингом.
          Минимальный блок «интеграция с существующей базой» снял бы 90% вопросов.
            0
            Да уж какой тут маркетинг? Тут в посте всего две мысли «мы сделали тулзу для проверки постгресов» и «ищем добровольцев» )))

            Минимальный блок «интеграция с существующей базой» снял бы 90% вопросов.

            Согласен, если мне это кажется очевидным моментом, то для нового пользователя это конечно не так. Мне кажется все сервисы пытаются сделать интеграцию как можно проще, в 1-2-3 клика/команды и плюс стартовая страница с инструкцией. В нашем случае все точно также, в самом простом варианте одной командой скачивается агент и через пайп запускается его установка. В демке кстати есть страница с описанием установки.

            Еще раз спасибо за фидбек.
              0
              В вашем кейсе процесс интеграции (установка, настройка агента) должен быть описан в статье, в документации на сайте, в каком-то хелпе в демке, а так же присутствовать в виде видео-инструкции. В вашем случае работает правило «Нет агента — нет клиента».
                0
                Понял, принял, исправлюсь.
                  +1
                  Про устройство агента тоже можно было бы рассказать. На чем написан, какие метрики собирает, можно ли настраивать кастомные метрики, есть ли офлайн режим работы, есть ли алерты, анализирует ли этот агент запросы.
                    0
                    Агент написан на Go, умеет собирать системные метрики, метрики постгреса и баунсера.
                    Кастомных метрик и оффлайн режима пока нет, эти фичи планировалось добаивть в случае открытия кода агента (когда внутреннее апи агента стабилизируется). Алертов нет, т.к. это не задача агента. По запросам собираются только метрики на основе pg_stat_statements, более глубого анализа запросов пока нет (есть возможность отключения трекинга текстов запросов чтобы не слать их в наш сервис, вместо текстов будут queryid). Код агента в перспективе планируется открыть, но пока не до этого.

                    Вообще конечно вы мне дали массу набросков на еще одну статью)))
                      0
                      С алертами не соглашусь, если ваш агент собирает системные метрики такие как использование диска и памяти, то логично что пользователь захочет алерты по этим метрикам. Ну не ставить же рядом забикс для мониторинга одной машины с постргесом. Если для онлайн режима алерт шлет ваш сервер, то для офлайн режима логично чтобы это делал сам агент.

                      Мне нравиться подход atop, пишем все в логи, потом можем просматривать туда/сюда в консоле.
                      Мне почему-то кажется что такой же подход должен быть и у вас. Один агент собирает все в файлы, второй агент шлет все это на сервер для дальнейшего анализа, третий агент отвечает чисто за алерты всякие(если сеть доступна то шлем алерт на сервер, который дальше шлет сообщение в телегу/вайбер/ватсап/зум, если сети нет — то алерт по тому что настроил клиент). Консольный клиент для просмотре того что попало в логи, без аналитики. Все что через веб с аналитикой. Соответственно консоль с минимумом функций и простым алертом — бесплатный тариф. Веб с аналитикой и разными видами алертов — уже платный тариф.
                        0
                        > Если для онлайн режима алерт шлет ваш сервер, то для офлайн режима логично чтобы это делал сам агент.

                        Боюсь что это сильно усложнит настройку агента для пользователя (как минимум надо указывать тип нотификации и реквизиты куда их отправлять). Установка агента же должна быть простой как палка. Но как доп. фича — почему бы и нет.

                        Описанный вами вариант с множеством агентов напоминает мне связку prometheus, alertmanager плюс экспортеры на любой вкус. Это подходящий вариант когда есть задача сделать мониторинг уровня инфраструктуры. Но в случае saas мониторингов для агентов важен подход быстро запустить и начать сбор/отправку метрик.

                        Еще добавлю про системные метрики — их сбор нужен потому что рассматривать администрирование постгреса в отрыве от системы просто невозможно. Поэтому сервису нужен весь «комплект» — метрики системы и постгреса. Сбор метрик с агента системами клиента кстати заложен в архитектуру агента. Но пока непонятно насколько оно надо.
        +3
        Посмотрел демо, не очень понятно, что делает продукт.
        Вернее создается ощущение, что он делает, то, что выводится парой запросов.
        Если это действительно система анализа и рекомендаций, то в демо данный функционал не отражен.
        Уберите от греха подальше, это прототип пустышка, заявлять о нем несколько рано, если он действительно претендует на то, о чем написано.
          0
          Согласен, в демо выводится довольно мало рекомендаций, там под капотом дефолтная база с тихо шуршащим pgbench. Но если собрать данные с нормальной staging/production базы то рекомендаций выводится существенно больше. Ок понял, над стендом под демо придется поработать дополнительно. Спасибо!
          0
          pghero и понятный и простой, делает все тоже самое
            0
            Знаком c pghero да, отличается в лучшую сторону он пока тем что в нем есть небольшое количество графиков.
            Насколько я помню все пороговые значения для рекомендаций там захардкожены и в целом решение не совсем универсальное. В weaponry для выработки рекомендации может быть обработка от одного до нескольких связанных параметров или изменяющихся величин и на их основе будет выдана рекомендация подходящая для конкретного сетапа.
            Проверяемых сущностей в weaponry больше, например сейчас в коде 230 функций проверки которые проверяют конкретные вещи на разные отклонения.
            0

            Попробовал зарегистрироваться — ошибка. Проверьте все ли у вас живо там

              0
              Регистрация пока ограничена (нужен инвайт ключ, без него будет HTTP 422), чтоб зарегистрироваться напишите на team@weaponry.io.
              0

              Я правильно понимаю что здесь предлагается скачать какой-то бинарный файл из интернета, создать в моей базе для него суперпользователя и запустить его чтобы он отправлял какие-то данные туда в интернет на чужой сайт? И еще платить за это?

                0
                Как бы дико это не звучало, но да, всё так. Но как всегда есть нюансы:
                — запустить можно и без суперюзера (часть метрик просто не соберется);
                — можно сказать агенту не отправлять тексты запросов (только queryid, чтоб пользователь хоть как-то мог ассоциировать запрос из веб-морды с запросом у себя в базе);
                — код агента можно запросить для аудита (в перспективе его планируется вообще открыть, как только внутри у него все более-менее устаканится);
                — если вы готовы к тестированию, то конечно предпочтительно тестировать на тестовых базах.
                — ах да, платить пока ни за что не нужно.

                Понимаю озабоченность, но увы, практически у всех агентов любых saas такие условия и они обоснованы тем чтобы предоставить пользователю полную функциональность от сервиса.
                  0

                  Ну я, в целом, понимаю почему было принято каждое из этих решений.
                  Однако, код агента обязательно нужно сделать открытым — если я вижу что конкретно оно может отправлять — у меня к нему больше доверия. Конечно, если он не выполняет "eval(то что получил от сервера)".
                  И стоит все-таки ограничить права. Ему правда нужны superuser и права на запись/создание таблиц?

                    0
                    Исключительные права (пока речь не идет о SUPERUSER) нужны для двух задач:
                    1. для выполнения ls функций из семейства Generic file access functions
                    2. просмотра текста запросов в pg_stat_activity.

                    Самый простой вариант (для нескилованного пользователя) это дать SUPERUSER. Правильный же вариант это дать права от встроенных ролей pg_read_server_files и pg_monitor (которая в свою очередь состоит из трех других ролей). С расширенными ролями не все просто, они появились относительно недавно и в старых версиях PG их нет.

                    Создание таблиц и тем более какая-либо запись в БД (или на файловую систему) со стороны агента отсутствует (все таки агент должен быть наблюдателем и не вмешиваться в работу БД и сервера).

                    Вобщем можно обойтись и без суперюзера, это усложнит настройку со стороны юзера — проверить что есть нужные роли, дать их. А если ролей нет, то все равно, либо дать суперюзера, либо частично потерять в метриках.

                    upd. еще п.3 нужно конфиги прочитать (нужна pg_monitor)

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое