Задержка действия AutoScaling, вызванного тревогой CloudWatch - PullRequest
Новая
       18

Задержка действия AutoScaling, вызванного тревогой CloudWatch

0 голосов
/ 03 января 2019

У меня есть группа автомасштабирования EC2 с масштабированием, инициируемым пошаговой политикой.Порог политики, похоже, определен правильно, но действие задерживается на 4-5 минут.Кажется, это отражено в журналах аварий: 

"newState": {
    "stateValue": "ALARM",
    "stateReason": "Threshold Crossed: 1 out of the last 1 datapoints [548.0 (03/01/19 20:27:00)] was greater than the threshold (160.0) (minimum 1 datapoint for OK -> ALARM transition).",
    "stateReasonData": {
      "version": "1.0",
      "queryDate": "2019-01-03T20:31:31.936+0000",
      "startDate": "2019-01-03T20:27:00.000+0000",
      "statistic": "Sum",
      "period": 60,
      "recentDatapoints": [
        548
      ],
      "threshold": 160
    }
  }

И в журнале активности ASG: 

At 2019-01-03T20:31:31Z a monitor alarm scale-out-alarm in state ALARM triggered policy scale-out-policy changing the desired capacity from 1 to 4. At 2019-01-03T20:32:01Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 1 to 4.

Обратите внимание, что порог был преодолен в 20:27:00 во время действиябыл взят в 20:31:31.Похоже, что они коррелируют с «startDate» и «queryDate» в журнале, хотя я не нашел никакой документации по этим свойствам.

Это просто случайные задержки в CloudWatch, или естьЕще одна причина такой задержки?

ASG не масштабировалась в течение длительного периода времени до этого, поэтому, похоже, она не связана с прогревом / перезарядкой.

ОбаEvaluationPeriods и DatapointsToAlarm равны 1.

После некоторого дальнейшего исследования кажется, что задержка намного больше, когда тревога основана на метриках RequestCount ALB, чем для ECU CPUUtilization.Имеет ли это смысл?

...