Неизвестный всплеск «Приблизительного среднего возраста самого старого сообщения» matrix AWS

#amazon-web-services #amazon-ec2 #amazon-sqs #amazon-cloudwatch

#amazon-веб-сервисы #amazon-ec2 #amazon-sqs #amazon -cloudwatch

Вопрос:

Я получал следующее тревожное сообщение ежедневно в одно и то же время от моего Amazon SQS.

Вы получаете это электронное письмо, потому что ваш сигнал тревоги Amazon CloudWatch «Старые сообщения в SQS» в регионе {мой регион} перешел в состояние ТРЕВОГИ, поскольку «Порог превышен: 1 из последних 1 точек данных [183.0 (30/09/20 00:06:00)] был больше или равен пороговому значению(180.0) (минимум 1 точка данных для перехода OK -> ALARM).» в «Среда, 30 сентября 2020 г. 00: 07: 22 UTC».

Сведения о тревоге:

  • Название: старые сообщения в SQS
  • Описание: Обновления Abc занимают слишком много времени. Проверьте процессор и очередь.
  • Изменение состояния: OK -> ТРЕВОГА
  • Причина изменения состояния: пороговое значение превышено: 1 из последних 1 точек данных [183.0 (30/09/20 00:06:00)] было больше или равно пороговому значению (180.0) (минимум 1 точка данных для перехода OK -> ALARM).
  • Временная метка: среда, 30 сентября 2020 г. 00: 07:22 UTC

Пороговое значение:

  • Тревога находится в состоянии ТРЕВОГИ, когда показатель превышает пороговое значение 180,0 в течение 60 секунд.

Отслеживаемый показатель:

  • Метрическое пространство имен: AWS / SQS
  • Метрическое имя: ApproximateAgeOfOldestMessage
  • Период: 60 секунд
  • Статистика: среднее
  • Единица измерения: не указана

Действия по изменению состояния:

  • ОК:
  • НЕДОСТАТОЧНЫЕ_ДАННЫЕ:

Итак, я проверил cloudwatch и посмотрел, что происходит. Итак, я определил, что загрузка ЦП снижается одновременно с тем экземпляром, который используется для обработки сообщений в SQS. Поэтому я решил, что количество сообщений в SQS увеличилось из-за сбоя сервера.

Самое старое сообщение SQS

Загрузка процессора

Но я не могу определить, почему сервер выходит из строя в одно и то же время каждый день. Я проверил следующее

  • Моментальные снимки EC2 — нет автоматических расписаний
  • Моментальные снимки RDS — на тот момент автоматизированных расписаний не было
  • Задания Cron на сервере

Есть ли кто-нибудь, у кого есть такой опыт, будет высоко оценен, чтобы определить, в чем именно заключается проблема.

Ответ №1:

Это очень поздно для вечеринки, и я предполагаю, что к настоящему времени вы либо поняли это, либо пошли дальше. Делюсь некоторыми мыслями для потомков.

Показатель, который превысил пороговое значение в 3 минуты, — это возраст элемента в очереди SQS. Причиной предупреждения не обязательно является отказ экземпляра, обрабатывающего сообщения, но может быть то, что процедура обработки заблокирована (ожидает) чего-то внешнего. Это может быть длительный сетевой вызов или что-то в этом роде.

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

Что бы я сделал в этой ситуации:

  1. Добавьте / проверьте журналы cloudwatch, которые отправляются в рамках процедуры обработки, и убедитесь, что обработка не застряла.

  2. Проверьте события / журналы экземпляра (под ними я подразумеваю запуск / остановку экземпляра, обслуживание и т. Д. чтобы убедиться, что ничто внешнее не повлияло на мой экземпляр обработки)

  3. В ряде случаев ответом может быть ошибка на стороне Amazon, поэтому, если застрял, обратитесь в службу поддержки Amazon.