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