Исключительные права (пока речь не идет о SUPERUSER) нужны для двух задач:
1. для выполнения ls функций из семейства Generic file access functions
2. просмотра текста запросов в pg_stat_activity.
Самый простой вариант (для нескилованного пользователя) это дать SUPERUSER. Правильный же вариант это дать права от встроенных ролей pg_read_server_files и pg_monitor (которая в свою очередь состоит из трех других ролей). С расширенными ролями не все просто, они появились относительно недавно и в старых версиях PG их нет.
Создание таблиц и тем более какая-либо запись в БД (или на файловую систему) со стороны агента отсутствует (все таки агент должен быть наблюдателем и не вмешиваться в работу БД и сервера).
Вобщем можно обойтись и без суперюзера, это усложнит настройку со стороны юзера — проверить что есть нужные роли, дать их. А если ролей нет, то все равно, либо дать суперюзера, либо частично потерять в метриках.
upd. еще п.3 нужно конфиги прочитать (нужна pg_monitor)
Как бы дико это не звучало, но да, всё так. Но как всегда есть нюансы:
— запустить можно и без суперюзера (часть метрик просто не соберется);
— можно сказать агенту не отправлять тексты запросов (только queryid, чтоб пользователь хоть как-то мог ассоциировать запрос из веб-морды с запросом у себя в базе);
— код агента можно запросить для аудита (в перспективе его планируется вообще открыть, как только внутри у него все более-менее устаканится);
— если вы готовы к тестированию, то конечно предпочтительно тестировать на тестовых базах.
— ах да, платить пока ни за что не нужно.
Понимаю озабоченность, но увы, практически у всех агентов любых saas такие условия и они обоснованы тем чтобы предоставить пользователю полную функциональность от сервиса.
> Если для онлайн режима алерт шлет ваш сервер, то для офлайн режима логично чтобы это делал сам агент.
Боюсь что это сильно усложнит настройку агента для пользователя (как минимум надо указывать тип нотификации и реквизиты куда их отправлять). Установка агента же должна быть простой как палка. Но как доп. фича — почему бы и нет.
Описанный вами вариант с множеством агентов напоминает мне связку prometheus, alertmanager плюс экспортеры на любой вкус. Это подходящий вариант когда есть задача сделать мониторинг уровня инфраструктуры. Но в случае saas мониторингов для агентов важен подход быстро запустить и начать сбор/отправку метрик.
Еще добавлю про системные метрики — их сбор нужен потому что рассматривать администрирование постгреса в отрыве от системы просто невозможно. Поэтому сервису нужен весь «комплект» — метрики системы и постгреса. Сбор метрик с агента системами клиента кстати заложен в архитектуру агента. Но пока непонятно насколько оно надо.
Агент написан на Go, умеет собирать системные метрики, метрики постгреса и баунсера.
Кастомных метрик и оффлайн режима пока нет, эти фичи планировалось добаивть в случае открытия кода агента (когда внутреннее апи агента стабилизируется). Алертов нет, т.к. это не задача агента. По запросам собираются только метрики на основе pg_stat_statements, более глубого анализа запросов пока нет (есть возможность отключения трекинга текстов запросов чтобы не слать их в наш сервис, вместо текстов будут queryid). Код агента в перспективе планируется открыть, но пока не до этого.
Вообще конечно вы мне дали массу набросков на еще одну статью)))
Да уж какой тут маркетинг? Тут в посте всего две мысли «мы сделали тулзу для проверки постгресов» и «ищем добровольцев» )))
Минимальный блок «интеграция с существующей базой» снял бы 90% вопросов.
Согласен, если мне это кажется очевидным моментом, то для нового пользователя это конечно не так. Мне кажется все сервисы пытаются сделать интеграцию как можно проще, в 1-2-3 клика/команды и плюс стартовая страница с инструкцией. В нашем случае все точно также, в самом простом варианте одной командой скачивается агент и через пайп запускается его установка. В демке кстати есть страница с описанием установки.
Знаком c pghero да, отличается в лучшую сторону он пока тем что в нем есть небольшое количество графиков.
Насколько я помню все пороговые значения для рекомендаций там захардкожены и в целом решение не совсем универсальное. В weaponry для выработки рекомендации может быть обработка от одного до нескольких связанных параметров или изменяющихся величин и на их основе будет выдана рекомендация подходящая для конкретного сетапа.
Проверяемых сущностей в weaponry больше, например сейчас в коде 230 функций проверки которые проверяют конкретные вещи на разные отклонения.
Согласен, в демо выводится довольно мало рекомендаций, там под капотом дефолтная база с тихо шуршащим pgbench. Но если собрать данные с нормальной staging/production базы то рекомендаций выводится существенно больше. Ок понял, над стендом под демо придется поработать дополнительно. Спасибо!
Я постарался как раз таки не перегружать статью нудными и длинными описаниями. Вот про Pricing хорошее замечание, там надо будет написать про тестовый режим.
думал над этим, пока не пришел к внутреннему согласию в плане того как это должно быть в интерфейсе… либо через меню где юзер выбирает базу из списка (удобно все имена перед глазами), либо юзер вводит название (проще запилить, но юзеру надо точно помнить имя базы)
Олег, про графику я серьезно как-то не думал, т.к. сейчас есть большое обилие графических мониторингов и смысла делать еще один… для рисования графиков в консоли… нууу не знаю, по-моему очень сомнительно )))
1. для выполнения ls функций из семейства Generic file access functions
2. просмотра текста запросов в pg_stat_activity.
Самый простой вариант (для нескилованного пользователя) это дать SUPERUSER. Правильный же вариант это дать права от встроенных ролей pg_read_server_files и pg_monitor (которая в свою очередь состоит из трех других ролей). С расширенными ролями не все просто, они появились относительно недавно и в старых версиях PG их нет.
Создание таблиц и тем более какая-либо запись в БД (или на файловую систему) со стороны агента отсутствует (все таки агент должен быть наблюдателем и не вмешиваться в работу БД и сервера).
Вобщем можно обойтись и без суперюзера, это усложнит настройку со стороны юзера — проверить что есть нужные роли, дать их. А если ролей нет, то все равно, либо дать суперюзера, либо частично потерять в метриках.
upd. еще п.3 нужно конфиги прочитать (нужна pg_monitor)
— запустить можно и без суперюзера (часть метрик просто не соберется);
— можно сказать агенту не отправлять тексты запросов (только queryid, чтоб пользователь хоть как-то мог ассоциировать запрос из веб-морды с запросом у себя в базе);
— код агента можно запросить для аудита (в перспективе его планируется вообще открыть, как только внутри у него все более-менее устаканится);
— если вы готовы к тестированию, то конечно предпочтительно тестировать на тестовых базах.
— ах да, платить пока ни за что не нужно.
Понимаю озабоченность, но увы, практически у всех агентов любых saas такие условия и они обоснованы тем чтобы предоставить пользователю полную функциональность от сервиса.
Боюсь что это сильно усложнит настройку агента для пользователя (как минимум надо указывать тип нотификации и реквизиты куда их отправлять). Установка агента же должна быть простой как палка. Но как доп. фича — почему бы и нет.
Описанный вами вариант с множеством агентов напоминает мне связку prometheus, alertmanager плюс экспортеры на любой вкус. Это подходящий вариант когда есть задача сделать мониторинг уровня инфраструктуры. Но в случае saas мониторингов для агентов важен подход быстро запустить и начать сбор/отправку метрик.
Еще добавлю про системные метрики — их сбор нужен потому что рассматривать администрирование постгреса в отрыве от системы просто невозможно. Поэтому сервису нужен весь «комплект» — метрики системы и постгреса. Сбор метрик с агента системами клиента кстати заложен в архитектуру агента. Но пока непонятно насколько оно надо.
Кастомных метрик и оффлайн режима пока нет, эти фичи планировалось добаивть в случае открытия кода агента (когда внутреннее апи агента стабилизируется). Алертов нет, т.к. это не задача агента. По запросам собираются только метрики на основе pg_stat_statements, более глубого анализа запросов пока нет (есть возможность отключения трекинга текстов запросов чтобы не слать их в наш сервис, вместо текстов будут queryid). Код агента в перспективе планируется открыть, но пока не до этого.
Вообще конечно вы мне дали массу набросков на еще одну статью)))
Согласен, если мне это кажется очевидным моментом, то для нового пользователя это конечно не так. Мне кажется все сервисы пытаются сделать интеграцию как можно проще, в 1-2-3 клика/команды и плюс стартовая страница с инструкцией. В нашем случае все точно также, в самом простом варианте одной командой скачивается агент и через пайп запускается его установка. В демке кстати есть страница с описанием установки.
Еще раз спасибо за фидбек.
Насколько я помню все пороговые значения для рекомендаций там захардкожены и в целом решение не совсем универсальное. В weaponry для выработки рекомендации может быть обработка от одного до нескольких связанных параметров или изменяющихся величин и на их основе будет выдана рекомендация подходящая для конкретного сетапа.
Проверяемых сущностей в weaponry больше, например сейчас в коде 230 функций проверки которые проверяют конкретные вещи на разные отклонения.
нужно скомпилироваться самому, по идее у вас должен стоять только go-1.11, а дальше так:
в след. абзаце нашлась еще одна битая ссылка.