Как и в случае любых сообщений о сбоях, нетехнический читатель будет в первую очередь стремиться понять:
- Как долго это было?
- Насколько это было плохо?
Метрики Amazon CloudWatch предоставляют следующие метрики для очередей SQS, которые могут помочь ответить на эти вопросы:
- NumberOfMessagesSent: количество сообщений, добавленных в очередь.
- NumberOfMessagesReceived: количество сообщений, возвращаемых вызовами к действию API ReceiveMessage.
- ApproximateNumberOfMessagesVisible: количество сообщений, доступных для извлечения из очереди.
При правильном отображении эти метрики могут быть мощными наглядными пособиями при описании задержек при обработке очереди. Вот несколько примеров из-за сбоя, который я испытал, когда способность задания обрабатывать сообщения очереди была сильно снижена:
NumberOfMessagesSent & NumberOfMessagesReceived
- Тип графика: линейный график
- Статистика: Сумма
- Период: 5 минут
Этот график отображает контраст между отправленными и полученными сообщениями, что помогает определить, какой компонент обработки отвечает за задержку. На этом графике полученная метрика резко падает, в то время как отправленная метрика продолжает свою обычную тенденцию, поэтому мы можем заключить, что проблема заключается в компоненте чтения очереди, а не в компоненте записи очереди.
Отвечает ли это как долго / как плохо было событие? Да; описывает процессы, затронутые с течением времени.
NumberOfMessagesReceived & ApproximateNumberOfMessagesVisible
- Тип графика: График с накоплением
- Статистика: Сумма
- Период: 5 минут
Этот график отображает глубину очереди поверх полученных сообщений, что помогает показать, насколько далеко зарезервирована очередь и как она восстановлена. На этом графике мы видим, что глубина очереди резко увеличилась, когда у компонента чтения очереди возникли проблемы, и начала восстанавливаться, когда компонент чтения очереди снова начал читать сообщения.
Отвечает ли это как долго / как плохо было событие? Да; описывает сообщения, затронутые с течением времени.
Обсуждение графиков
На обоих графиках обработку очереди обычно можно считать работоспособной, когда линии перекрываются, и нездоровой, когда линии расходятся. Это простой шаблон для обучения нетехнических членов команды, и он может помочь им быстро определить, где и как возникают проблемы при представлении этих графиков.
Чтобы дополнительно обозначить конкретные точки на графиках, вы можете просто их комментировать:
Графические Советы:
- Маркировка узлов и осей.
- Используйте согласованные цвета для сопоставления метрик на графиках. Обратите внимание, что NumberOfMessagesReceived в обоих графиках оранжевого цвета; это поможет визуализировать одну и ту же метрику на разных графиках.
- Вертикально выровняйте графики, которые описывают похожие показатели, чтобы их было легче сравнивать во времени.
Примечание. Я отформатировал эти графики для представления в StackExchange, поэтому они не обязательно должны отображаться в посмертном отключении. Я явно удалил значения с левой оси, чтобы скрыть их от StackExchange; Вы хотите, чтобы держать их в своих вскрытиях.
Дополнительные советы
- Расширьте возможности своей команды: после обучения членов вашей команды чтению этих графиков, нет причин скрывать их. Подумайте о настройке CloudWatch Dashboard и предоставьте своим нетехническим членам IAM доступ только для чтения к CloudWatch , чтобы они могли просматривать эти графики в любое время.
- Настройка уведомлений: рассмотрите возможность настройки сигналов тревоги Cloudwatch на основе метрики ApproximateNumberOfMessagesVisible, если она превышает некоторое согласованное высокое значение, и подпишитесь на членов группы, чтобы уведомить их о потенциальных проблемах. Алармы Cloudwatch имеют поля описания, которые отправляются вместе с электронными письмами с уведомлением - обязательно добавьте удобочитаемое описание, чтобы помочь вашим нетехническим участникам распространять аларм.
- Исследовать Другие данные: Per комментарий Евгения , изучить другие данные , помимо того, что обеспечивает CloudWatch и думать о том , как вы можете передать , что данные в вашей команде. Его пример использования времени жизни сообщения в очереди для создания гистограммы является отличным примером этого творческого мышления, и его можно реализовать, зарегистрировав в приложении время отправки и получения сообщений. Вы можете получить сообщение Sent Timestamp с помощью атрибута SentTimeStamp для каждого сообщения очереди ответа API ReceiveMessage. Подробнее здесь .
