Мониторинг отложенной обработки Amazon SQS

У меня есть ряд приложений, которые потребляют сообщения из очередей SQS. Если по какой-то причине один из этих потребителей выйдет из строя и перестанет получать сообщения, я хочу получить уведомление. Как лучше всего это сделать?

Обратите внимание, что в некоторых из этих очередей может быть только одно сообщение, помещаемое в очередь каждые 2-3 дня, поэтому ждать, пока количество сообщений в очереди вызовет уведомление, для меня не лучший вариант.

Я ищу что-то, что может отслеживать очередь SQS и говорить: «Это сообщение находится здесь в течение часа, и ничто его не обработало ... дайте кому-нибудь знать».


amazon-sqs
person Warrick FitzGerald    schedule 18.12.2015    source источник
comment
Я предполагаю, что необходимое решение может зависеть от других сервисов AWS. Чтобы отслеживать то, что вы описали, вы можете использовать сервис Amazon CloudWatch, который позволяет отслеживать состояние очереди SQS. Ознакомьтесь с документацией по этому поводу. Другой вопрос - как реализовать отслеживание без установки будильников на CloudWatch. Если вы согласны с задержкой в ​​1 час после сбоя службы, вы можете настроить ежечасную лямбда-функцию на AWS, чтобы отслеживать и уведомлять за вас. Вы можете также разработать собственное решение в качестве мониторинга cronjob   -  person Yerken    schedule 18.12.2015
comment
У службы облачных часов, похоже, нет счетчика, который бы отвечал моим потребностям. Может, я просто скучаю по нему? Идея Lambda интересна ... Я разберусь с ней, спасибо.   -  person Warrick FitzGerald    schedule 18.12.2015
comment
У меня есть ряд вопросов, которые помогут найти лучшее решение. Как часто вы опрашиваете очередь? Вы используете длительный опрос и опросы постоянно (что кажется немного чрезмерным, учитывая объем вашего сообщения) или просто опрашиваете каждые несколько часов? Сколько времени нужно на обработку сообщения? Вас больше интересует мониторинг сообщений в очереди или приложение, получающее сообщения из очереди?   -  person JaredHatfield    schedule 29.12.2015
comment
Мое приложение отправляет сообщения в тему SNS, которая затем имеет несколько подписчиков SQS. Тогда имеется несколько потребителей. Отдел X может отвечать за потребление из очереди A, а отдел Y может отвечать за потребление из очереди B. Как правило, мы не хотим, чтобы сообщение находилось в очереди SQS дольше, чем скажем 10 минут. Если он находится в Очереди более 10 минут, либо потребитель по какой-то причине больше не обрабатывает запросы ... либо он не успевает за ним. Я пытаюсь создать систему предупреждений, которая сообщает мне, что любой из этих двух случаев является предварительным.   -  person Warrick FitzGerald    schedule 29.12.2015

Ответы (1)


arrow_upward
0
arrow_downward

Возможное решение, которое у меня в голове (возможно, не самое элегантное), которое вообще не требует использования CloudWatch (согласно комментарию OP, необходимое отслеживание не может быть реализовано с помощью сигналов тревоги CloudWatch). Предположим, у вас есть очередь для обработки в службе, а принимающая сторона реализована посредством длительного опроса. Запустите функцию Lambda (скажем, ежечасно), прослушивая очередь и читая сообщения, но никогда не удаляя (служба удаляет сообщения после обработки). В Очереди установите для параметра Максимальное количество приемов любое значение, которое вы хотите, скажем 3. Если лямбда-функция запускалась 3 раза и все три раза сообщение присутствовало в очереди, сообщение будет помещено в очередь недоставленных писем (автоматически, если политика повторного извлечения задана. установленный). Всякий раз, когда новое сообщение помещается в очередь недоставленных сообщений, это хороший показатель того, что ваша служба либо не работает, либо недостаточно быстро обрабатывает запросы. Все переменные можно изменить в соответствии с вашими потребностями

person Yerken    schedule 18.12.2015