в контексте конкретно этого примера - "взять содержимое файла и показать в интерфейсе", то такой функциональности нет. Есть реализация но на других инструментах - pgpro_stats, его планировщик и метрики, которые есть в PPEM и добиться того же самого. Можно почитать тут про pgpro_stats и реализацию в PPEM.
По п.1 вроде есть фильтры, посмотрите в пример конфига менеджера в ldap-секцию. По п.2 из-за переработки архитектуры менеджер и база репозитория теперь "отвязаны" друг от друга и теперь легко могут жить отдельно.
upd. ну е-мае... я два раза не повторяю не повторяю)
По п.1 вроде есть фильтры, посмотрите в пример конфига менеджера в ldap-секцию. По п.2 из-за переработки архитектуры менеджер и база репозитория теперь "отвязаны" друг от друга и теперь легко могут жить отдельно.
Просто в контексте push модели для otel коллектора и pull для эндпойнта прометея непонятно куда и какое число улетит и где будет актуальное на момент времени.
prometheus экспортер не умеет в push модель, только pull. а в случае прометея все зависит от того как настроите сам прометей
Да это кэширование на уровне экспортера, регулируется параметром metric_expiration экспортера. Экспортер не знает когда к нему придет скрейпер, поэтому удерживает метрики некоторые время которые могли пропасть (в плане постгреса это характерно для GAUGE-подобных метрик activity и locks).
А планируется ли подружить это с pg_profile для доступа к данным по отдельным запросам?
Интеграция с pg_profile пока не рассматривалась. А для сбора метрик по отдельным запросам можно включить соотв. плагины (начинаются с префикса statements) и на мой скромный взгляд, за счет мощи promql/metricsql/grafana получить гораздо большие возможности.
Метрики pgbouncer, patroni будут?
pgbouncer определенно да, patroni скорей всего нет, т.к. целевой HA менеджер это BiHA, а patroni с пониженным приоритетом.
если речь про общедоступные репозитории дистрибутивов, то тут сложно сказать - управляют ими независимые мейнтейнеры со своими правилами что и когда добавлять
Привет, вы все верно говорите, анализировать метрики, вчитываться в их HELP описания это нудная рутина, я сам много раз играл в эту игру. По дашбордам работы ведутся и в след. релизе дашборды будут идти в комплекте.
1) в ближайшее время точно нет, в долгосрочной перспективе с высокой вероятностью библиотека и/или ресивер будут открыты
2) да, может. подробнее об этом можно прочитать в документации по файлу конфигурации
3) сбор метрик - да, достаточно указать реквизиты подключения. сбор логов - нет, т.к. требуется доступ к каталогу с логами
4) не могу ответить на вопрос, не пробовал их скрещивать, но если там теже самый вьюхи доступные через SQL, то все должно получиться
5) этот пробел в документации мы заполним, но да, должно хватить pg_monitor роли и могут потребоваться гранты на execute на pg_ls_dir и pg_stat_file (требуется для сбора осиротевших файлов).
Как-то давным давно, на одной из постгресовых конференций я познакомился с Виталием. Тогда мы общались на разные постгресовые темы, обсуждали постгрес, инструменты вокруг него. И в то время были популярны истории про HighAvailability - на этой волне популярности появлялись разные инструменты. Виталий не прошел мимо и создал postgresql_cluster (https://github.com/vitabaks/postgresql_cluster) - автоматизацию которая объединила в себе набор несвязанных компонентов в один целостный инструмент. Инструмент получился весьма удачный и я нередко отвечая на вопросы про HA, рекомендовал присмотреться и попробовать postgresql_cluster.
Прошло несколько лет, инструмент не только продолжил развитие, но и перерос в продукт. Это очень круто - за столь длительное время, автор не потерял к нему интерес и продолжает поддерживать и добавлять новые функции. Поддержка ПО мне всегда напоминала бесконечный марафонский забег без финишной прямой и чем дольше удается пробежать, тем больше это вызывает уважения.
Виталий ты супермегакрут, желаю тебе продолжать бежать, желаю находить силы для поддержки и развития, придумывать новые идеи для новых фич, получать больше пользователей и адекватной обратной связи, ну и вообще успехов!🍾🎉
Привет, те что в пакете это и есть отправная точка. На чтото более продвинутое к сожалению не хватает времени.
в контексте конкретно этого примера - "взять содержимое файла и показать в интерфейсе", то такой функциональности нет. Есть реализация но на других инструментах - pgpro_stats, его планировщик и метрики, которые есть в PPEM и добиться того же самого. Можно почитать тут про pgpro_stats и реализацию в PPEM.
ссылка в первом абзаце отдает 404
что есть в дашборде на данный момент?
забавно, рейтинг 45 и ни одного коммента )) коллеги наплюсовали?
По п.1 вроде есть фильтры, посмотрите в пример конфига менеджера в ldap-секцию. По п.2 из-за переработки архитектуры менеджер и база репозитория теперь "отвязаны" друг от друга и теперь легко могут жить отдельно.
upd. ну е-мае... я два раза не повторяю не повторяю)
По п.1 вроде есть фильтры, посмотрите в пример конфига менеджера в ldap-секцию. По п.2 из-за переработки архитектуры менеджер и база репозитория теперь "отвязаны" друг от друга и теперь легко могут жить отдельно.
пока только вторая, третья же еще не выпущена ))
Версии с открытыми исходниками не будет. Ближайшие 2-4 года точно не планируется.
Temboard является схожим по назначению продуктом и имеет часть функций которые есть в PPEM.
а продолжите мысль
prometheus экспортер не умеет в push модель, только pull. а в случае прометея все зависит от того как настроите сам прометей
Да это кэширование на уровне экспортера, регулируется параметром metric_expiration экспортера. Экспортер не знает когда к нему придет скрейпер, поэтому удерживает метрики некоторые время которые могли пропасть (в плане постгреса это характерно для GAUGE-подобных метрик activity и locks).
да, можете
Интеграция с pg_profile пока не рассматривалась. А для сбора метрик по отдельным запросам можно включить соотв. плагины (начинаются с префикса statements) и на мой скромный взгляд, за счет мощи promql/metricsql/grafana получить гораздо большие возможности.
pgbouncer определенно да, patroni скорей всего нет, т.к. целевой HA менеджер это BiHA, а patroni с пониженным приоритетом.
если речь про общедоступные репозитории дистрибутивов, то тут сложно сказать - управляют ими независимые мейнтейнеры со своими правилами что и когда добавлять
пока есть, но все это на уровне черновиков во внутрикорпоративной графане
Привет, вы все верно говорите, анализировать метрики, вчитываться в их HELP описания это нудная рутина, я сам много раз играл в эту игру. По дашбордам работы ведутся и в след. релизе дашборды будут идти в комплекте.
ммм, а что такое contrib и почему это должно там быть?
Вы все верно поняли, otel и даже больше, otel-collector, это OpenTelemetry Collector.
Про OpenTelemetry уже из каждого утюга вещают, по-моему otel скоро станет именем нарицательным как ксерокс
1) в ближайшее время точно нет, в долгосрочной перспективе с высокой вероятностью библиотека и/или ресивер будут открыты
2) да, может. подробнее об этом можно прочитать в документации по файлу конфигурации
3) сбор метрик - да, достаточно указать реквизиты подключения. сбор логов - нет, т.к. требуется доступ к каталогу с логами
4) не могу ответить на вопрос, не пробовал их скрещивать, но если там теже самый вьюхи доступные через SQL, то все должно получиться
5) этот пробел в документации мы заполним, но да, должно хватить pg_monitor роли и могут потребоваться гранты на execute на pg_ls_dir и pg_stat_file (требуется для сбора осиротевших файлов).
6) как обычно - bugs@postgrespro.ru
Как-то давным давно, на одной из постгресовых конференций я познакомился с Виталием. Тогда мы общались на разные постгресовые темы, обсуждали постгрес, инструменты вокруг него. И в то время были популярны истории про HighAvailability - на этой волне популярности появлялись разные инструменты. Виталий не прошел мимо и создал postgresql_cluster (https://github.com/vitabaks/postgresql_cluster) - автоматизацию которая объединила в себе набор несвязанных компонентов в один целостный инструмент. Инструмент получился весьма удачный и я нередко отвечая на вопросы про HA, рекомендовал присмотреться и попробовать postgresql_cluster.
Прошло несколько лет, инструмент не только продолжил развитие, но и перерос в продукт. Это очень круто - за столь длительное время, автор не потерял к нему интерес и продолжает поддерживать и добавлять новые функции. Поддержка ПО мне всегда напоминала бесконечный марафонский забег без финишной прямой и чем дольше удается пробежать, тем больше это вызывает уважения.
Виталий ты супермегакрут, желаю тебе продолжать бежать, желаю находить силы для поддержки и развития, придумывать новые идеи для новых фич, получать больше пользователей и адекватной обратной связи, ну и вообще успехов!🍾🎉
Всё, понял теперь, спасибо :)
Посмотрите тут.