Azure наблюдаемый показатель c значение по сравнению с фактическим показателем c значение для автоматического масштабирования - PullRequest
0 голосов
/ 05 мая 2020

У меня есть правило автомасштабирования, которое не срабатывает.

Правило out указывает, что если процентная доля ЦП выше 70%, тогда добавьте экземпляр. Продолжительность времени составляет 2 минуты, а период охлаждения - 2 минуты.

Когда я построил диаграмму показателей для сравнения фактического процента ЦП с наблюдаемым, я Ясно видно, что в моем процессоре есть всплески, но наблюдаемое, похоже, усредняет их за более длительный период времени, и я не знаю почему? Какую настройку я могу использовать в своих правилах шкалы для управления периодом времени, за который мое правило усредняет?

enter image description here

1 Ответ

1 голос
/ 06 мая 2020

Спасибо за вопрос! Вы можете исследовать Лучшие практики для автомасштабирования

Кроме того, важно понимать процесс колебания:

Рекомендуется тщательно выбирать разные пороговые значения для масштабирования и масштабирование в зависимости от практических ситуаций и не рекомендуется использовать настройки автомасштабирования, подобные приведенным ниже примерам, с одинаковыми или очень похожими пороговыми значениями для выходных и определенных условий:

Возьмите это в качестве примера:

Увеличьте количество экземпляров на 1 счет, если количество потоков <= 600 Уменьшите количество экземпляров на 1 счет, когда количество потоков> = 600

Теперь рассмотрите следующий процесс:

Предположим, есть два экземпляра для начала и тогда среднее количество потоков на экземпляр возрастает до 625.

Автоматическое масштабирование масштабируется при добавлении третьего экземпляра.

Затем предположим, что среднее количество потоков в экземпляре упадет до 575.

Перед уменьшением масштаба автоматическое масштабирование пытается оценить, каким будет конечное состояние, если оно будет увеличено. Например, le, 575 x 3 (текущее количество экземпляров) = 1725/2 (окончательное количество экземпляров при уменьшении) = 862,5 потока. Это означает, что автоматическое масштабирование должно быть немедленно масштабировано снова даже после масштабирования, если среднее количество потоков останется таким же или даже снизится лишь на небольшую величину. Однако при повторном масштабировании весь процесс повторится, что приведет к бесконечному l oop.

Чтобы избежать этой ситуации (называемой «колеблющейся»), автоматическое масштабирование не уменьшает масштаб вообще. Вместо этого он пропускает и повторно оценивает условие при следующем выполнении задания службы. Это может сбить с толку многих людей, потому что автоматическое масштабирование не будет работать, когда среднее количество потоков составляло 575.

Оценка во время масштабирования предназначена для предотвращения ситуаций «колебания», когда масштабирование и масштабирование действия постоянно go вперед и назад. Помните об этом поведении, когда вы выбираете одни и те же пороговые значения для горизонтального масштабирования и увеличения.

Мы рекомендуем выбрать адекватную границу между масштабированием и пороговыми значениями. В качестве примера рассмотрим следующую лучшую комбинацию правил.

Увеличить количество экземпляров на 1 счет, если CPU%> = 80

Уменьшить количество экземпляров на 1 счет, когда CPU% <= 60 </p>

Чтобы добавить к этому период охлаждения, который означает, что если произошла операция масштабирования вниз / вверх, даже если правило верно (пример - ЦП остается высоким), правило автоматического масштабирования не сработает. Если время охлаждения составляет 2 минуты, что означает, что если произошла операция уменьшения / увеличения масштаба, в течение следующих 2 минут, даже если правило верно, оно не будет запущено из-за периода охлаждения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...