По п.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.
Прошло несколько лет, инструмент не только продолжил развитие, но и перерос в продукт. Это очень круто - за столь длительное время, автор не потерял к нему интерес и продолжает поддерживать и добавлять новые функции. Поддержка ПО мне всегда напоминала бесконечный марафонский забег без финишной прямой и чем дольше удается пробежать, тем больше это вызывает уважения.
Виталий ты супермегакрут, желаю тебе продолжать бежать, желаю находить силы для поддержки и развития, придумывать новые идеи для новых фич, получать больше пользователей и адекватной обратной связи, ну и вообще успехов!🍾🎉
Но уплощение выполняется только если оно не приведет к появлению в плоском списке более join_collapse_limit элементов (значение параметра по умолчанию — 8). В данном примере при любых значениях параметра, меньших 5, узел JOINEXPR не будет уплощен.
Несколько раз перечитал, мне кажется что первое предложение противоречит второму. То есть первое предложение говорит "уплощать пока итоговое значение в списке меньше 8". Второе говорит наоборот "НЕ уплощать пока итоговое значение меньше 5+3"
Все ли верно в цитате? или таки в первом предложении есть лишняя частица "не"?
Автор статьи прямо указывает что НЕиспользовать большие страницы НЕ рекомендуется — Especially when not utilizing huge_pages (not recommended)
С моей точки зрения большие страницы имеет смысл использовать если памяти больше 8-16GB, на калькуляторах с меньшим объемом памяти лишняя суета с настройкой.
ссылка в первом абзаце отдает 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.
Прошло несколько лет, инструмент не только продолжил развитие, но и перерос в продукт. Это очень круто - за столь длительное время, автор не потерял к нему интерес и продолжает поддерживать и добавлять новые функции. Поддержка ПО мне всегда напоминала бесконечный марафонский забег без финишной прямой и чем дольше удается пробежать, тем больше это вызывает уважения.
Виталий ты супермегакрут, желаю тебе продолжать бежать, желаю находить силы для поддержки и развития, придумывать новые идеи для новых фич, получать больше пользователей и адекватной обратной связи, ну и вообще успехов!🍾🎉
Всё, понял теперь, спасибо :)
Посмотрите тут.
Несколько раз перечитал, мне кажется что первое предложение противоречит второму.
То есть первое предложение говорит "уплощать пока итоговое значение в списке меньше 8".
Второе говорит наоборот "НЕ уплощать пока итоговое значение меньше 5+3"
Все ли верно в цитате? или таки в первом предложении есть лишняя частица "не"?
С моей точки зрения большие страницы имеет смысл использовать если памяти больше 8-16GB, на калькуляторах с меньшим объемом памяти лишняя суета с настройкой.