Простое решение сложной проблемы с aws lambda
Если вы хотите перейти к коду, найдите его здесь
Этот сценарий, описанный ниже, происходит именно так, как описано (это НЕ вопрос с подвохом):
Есть лямбда, которая срабатывает от sqs, и у нее есть очередь недоставленных писем для сообщений, которые невозможно обработать. События, отправляемые в очередь, представляют собой простые сообщения json, состоящие только из id, содержащего уникальную строку (пример события показан ниже). Когда лямбда срабатывает, она сразу запускает рентгеновский сегмент, добавляя id сообщения в качестве аннотации. Эта аннотация позволяет нам искать следы, связанные с этим конкретным сообщением, в рентгеновском снимке.
{
"id": "fd450041-4cc2-4953-b997-64fd4a10fa31"
}
Тем не менее, есть некоторые странности в поведении приложения, которые запечатлены в видео ниже. В этом видео я отправляю в очередь четыре сообщения (четыре раза щелкнул вывод из cloudformation). Затем я жду несколько минут, пока не произойдет обработка (которая может включать повторные попытки).
Затем я проверяю очередь недоставленных сообщений и вижу, что она содержит четыре сообщения. Это означает, что исходная лямбда не смогла обработать ни одно из отправленных событий. Однако, когда я просматриваю журналы, я не вижу трассировки стека исключений(у меня в моем коде нет блоков catch, поэтому трассировки стека исключений будут распечатаны). эм>). Кроме того, когда я ищу следы для отправленного мной идентификатора, на рентгеновском снимке ничего не появляется. Все это показано в записи экрана ниже. Это, вероятно, заставляет нас спросить: «Что может происходить?»
Что тут происходит?
Ответ заключается в том, что лямбда-выполнение выполняется по тайм-ауту. Однако, как мы видели, это трудно диагностировать по следующим причинам:
- Нет предоставленной AWS метрики для тайм-аутов
- Журналы Lambda не содержат трассировку стека ошибок для тайм-аутов.
- Вызовы с истекшим временем ожидания не будут публиковать рентгеновские трассы (если время ожидания истекло до вызова закрытия для подсегмента).
- Вызовы с истекшим временем ожидания не вернут ответ (поэтому вы не можете использовать такие вещи, как идентификатор корреляции, для поиска в журналах).
* есть несколько способов, которые вы можете использовать, чтобы узнать, происходят ли тайм-ауты, но они не очень хороши. Вы можете найти их в разделе дополнений.
Что мы можем с этим поделать?
Поскольку не существует готовой метрики для тайм-аутов, если мы хотим видеть частоту этих событий, мы должны создать собственную метрику тайм-аута. Мы можем сделать это, используя возможности запроса cloudwatch logs Insights (определение облачного формирования можно найти здесь). После написания запроса (который засчитывается каждый раз, когда появляется фраза Время ожидания задачи истекло через), вы можете использовать его двумя способами, из которых я предпочитаю второй вариант:
- вы можете запустить запрос, когда подозреваете, что время ожидания ваших функций истекло
- из этого можно создать показатель, добавить его на панель инструментов и добавить на него сигналы тревоги
Эталонная архитектура
Созданный для этого примера стек cloudformation (созданный по этому сам шаблону) содержит следующие ресурсы:
Некоторые из соответствующих ресурсов, предоставляемых в этом стеке, включают:
- Лямбда-функция с превышением времени ожидания — лямбда запускает рентгеновскую трассу и (преднамеренно) истекает время ожидания. Запускается sqs и имеет dlq
- Пользовательская метрика cloudwatch для тайм-аутов — использует аналитику журналов cloudwatch для публикации точки данных со значением 1 каждый раз, когда в наших журналах функций появляется фраза Время ожидания выполнения задачи истекло.
- Тревога Cloudwatch, которая срабатывает, если превышено время ожидания более одного процента вызовов функций — использует математику метрики cloudwatch и пользовательскую метрику, созданную выше. Отправляет в тему sns при ее запуске, а также используется для развертывания функции отката.
- Панель инструментов Cloudwatch для визуализации метрик и сигналов тревоги — это позволяет нам визуализировать метрики и сигналы тревоги, чтобы увидеть, как данные проходят через нашу систему (включая упомянутые выше метрику и сигнал тревоги, а также стандартные метрики aws)
- Триггерная функция — включена для удобства; это лямбда, запускаемая GET-запросом (url-адрес указан как вывод стека), который помещает сообщения в очередь.
В шаблоне также задействованы различные другие «сантехнические» компоненты, не стесняйтесь просматривать их самостоятельно, чтобы увидеть их все.
Покажи мне доказательство
Давайте посмотрим, как эти тайм-ауты выглядят на нашей информационной панели cloudwatch, которая предоставляется с использованием того же шаблона sam, что и другие ресурсы. Обратите внимание, что он показывает, что очередь получает сообщения, функция вызывается, неудачных выполнений нет, а очередь недоставленных сообщений получает сообщения (все это стандартные метрики AWS). На последнем графике показана наша пользовательская метрика для количества тайм-аутов, а справа от нее у нас есть сигнал тревоги, когда функция истечет более 1% выполнений за пятиминутный период.
Заключение
Мы видели, что отладка тайм-аутов лямбда-выражения может быть затруднена, потому что стандартные инструменты от AWS (на удивление) не предоставляют метрики для тайм-аутов. Кроме того, тайм-ауты не будут отображать трассировку стека ошибок в журналах, а истекшие тайм-ауты выполнения не будут публиковать рентгеновские трассировки. Поэтому, чтобы получить представление о тайм-аутах, мы создали фильтр метрик, используя информацию из журналов CloudWatch, который ищет фразу «Время ожидания выполнения задачи истекло». Когда это происходит в журналах, он публикует точку данных для пользовательской метрики, называемой временем ожидания, со значением, равным единице. Затем мы использовали эту метрику несколькими способами: мы создали сигнал тревоги для этой метрики, чтобы если наша функция превышала время ожидания более одного процента, и мы использовали сигнал тревоги для автоматического отката наших канареечных развертываний.
Ссылки по теме
Дальнейшее чтение
Приложение
Как упоминалось ранее, существует несколько способов угадать наличие тайм-аутов, но это не рекомендуемое решение, поскольку оно не так объективно, как показанное решение. выше:
- Если вы используете API-шлюз и видите, что возвращается ошибка 503, скорее всего, это тайм-аут.
- Вы можете использовать метрику продолжительности — если продолжительность увеличивается, это может означать, что происходят тайм-ауты.
