Согласен с вами. Если мы хотим разобраться в причинах просадки и попытаться нивелировать эффект, то нужно "копать" в данном направлении. В этом все и дело. В статье - мы говорим только о сравнении в "лоб" as is и синтетических тестах.
Безусловно. Для подов и ноды были сконфигурированы соответствующие Taints и Tolerations. В рамках теста была выделенная нода для cnpg. Все "служебные" поды имели ограничения по запросам и лимитам ресурсов - "шум" был сведен к возможному минимум. Так же были выделеные гаранитрованые реквесты для пода cnpg равные по ресурсам native vm c Postgres.
mdb Postgres в YC имеет ключевое ограничение - 200 коннектов на ядро ( в вашей терминологии - оптимизацию)
"шумные" соседи - их "импакт" был в тестах исключен, но в реальном продуктовом кластере у вас не может быть ноды вообще с одним подом Postgres - нужны логи, метрики т.д. - всегда будет что-то служебное
Все тесты "синтестические" и каждый может сам на основе результатов этих тестов сделать свои собственные выводы и поделится ими с сообществом - почвой для которых и служит данный материал.
Я сделал пример без LLD, где-то написано что тут будет LLD? Изменить скрипт под ваши нужды не составит проблем, если у вас необходимость в мониторинге большого количества устройств с разной конфигурацией реализуйте LLD.
Не нужно рассматривать данный топик как инструкцию к проектированию и внедрению системы мониторинга — это туториал, в котором объясняется как работают все подобные системы и как сделать свое элементарное решение и понять как это работает. Речь идет все лишь о простом мониторинге ресурсов одного сервера.
Хотелось понять и разобраться как это работает, а установив готовую систему и включив в конфиге отображение нужных графиков это сделать не получилось. Данный способ минималистичен, и ведь большинству как раз нужно отображения всего нескольких показателей, а использовать для этого такие гиганты считаю не целесообразно.
Согласен с вами. Если мы хотим разобраться в причинах просадки и попытаться нивелировать эффект, то нужно "копать" в данном направлении. В этом все и дело. В статье - мы говорим только о сравнении в "лоб" as is и синтетических тестах.
Безусловно. Для подов и ноды были сконфигурированы соответствующие Taints и Tolerations. В рамках теста была выделенная нода для cnpg. Все "служебные" поды имели ограничения по запросам и лимитам ресурсов - "шум" был сведен к возможному минимум. Так же были выделеные гаранитрованые реквесты для пода cnpg равные по ресурсам native vm c Postgres.
конструктивно:
mdb Postgres в YC имеет ключевое ограничение - 200 коннектов на ядро ( в вашей терминологии - оптимизацию)
"шумные" соседи - их "импакт" был в тестах исключен, но в реальном продуктовом кластере у вас не может быть ноды вообще с одним подом Postgres - нужны логи, метрики т.д. - всегда будет что-то служебное
Все тесты "синтестические" и каждый может сам на основе результатов этих тестов сделать свои собственные выводы и поделится ими с сообществом - почвой для которых и служит данный материал.
Спасибо за Ваш комментарий.
Спасибо! Рад, что смог вас порадовать. Я учту ваши комментарии в будущих тестах.