Цель
Стремление к включению оповещения CloudWatch, когда сообщение из очереди SQS в функцию лямбда-функции превышает максимальное число повторов.
Проблема
Я предположил, что это будет легко, и NumberOfMessagesReceived metri c будет отражать это. Те, кто знаком с этим, знают, что это не так.
Решения
Решение "Limbo"
Моим быстрым и простым решением этой проблемы было введение " Limbo ", который действует как первый DLQ и в течение нескольких секунд передает сообщение в окончательный / фактический DLQ. В метриках это приводит к всплеску видимых сообщений в очереди "Limbo" metri c. Таким образом, наличие порога оповещения «> 0 » означает, что каждый раз, когда эта очередь получает сообщение, может быть выдано оповещение.
Однако полномочия над мной недовольны наличием очереди "Limbo" для каждого раза, когда мы хотим эту функцию.
Насколько мне удалось выяснить, есть некоторые альтернативные методы, но они кажутся хуже, чем Limbo Solution .
Новая лямбда-функция
Первый - это иметь новая лямбда-функция, которая использует SQS DLQ в качестве источника и генерирует предупреждение.
Lambda Runtime Interception
Во-вторых, иметь логарифм c внутри существующих лямбд (которые обрабатывают сообщения SQS), считывающие количество попыток повторения сообщения и его окончательного завершения. время оповещения. Этот вид устраняет преимущество использования очереди и политики повторного вождения в первую очередь и является чрезмерно спроектированным решением.
Metri c Maths
Последняя альтернатива, которую я могу придумать, - это использовать некоторые Metri c Maths, чтобы посмотреть на DLQ и вычислить, произошло ли увеличение последние X минут.
Все они кажутся странными и слишком сложными решениями того, что (я убежден) должно иметь простую реализацию. Как создать оповещение каждый раз, когда DLQ получает сообщение?