Как мы исправляем ошибки быстрее, чем два встряхивания ягненка хвостом.

В команде аналитиков Equinox Media мы ежедневно вызываем тысячи функций Lambda для выполнения различных задач обработки данных. Примеры варьируются от рутинного перетасовки файлов на S3 до более стимулирующих рекомендаций по фитнес-контенту в реальном времени в приложении Equinox +.

Поскольку мы полагаемся на Lambda, очень важно диагностировать проблемы как можно быстрее.

Вот схема процесса, который мы создали для этого:

Если вы также являетесь пользователем Lambda, как выглядят ваши предупреждения об ошибках? Если вы обнаружите, что изо всех сил пытаетесь понять, почему произошел сбой, или, что еще хуже, даже не подозревая, что он произошел, мы надеемся, что совместное использование нашего решения поможет вам стать более эффективным специалистом по бессерверным технологиям!

Шаг № 1: Создайте сигнал тревоги CloudWatch на основе метрики ошибок

После каждого запуска функции Lambda AWS по умолчанию отправляет несколько показателей в службу CloudWatch. Согласно документации AWS:

Метрики вызова - это бинарные индикаторы результата вызова. Например, если функция возвращает ошибку, Lambda отправляет метрику Errors со значением 1. Чтобы подсчитать количество ошибок функции, возникающих каждую минуту, просмотрите Sum метрики Errors с периодом в одну минуту.

Чтобы сообщить нам о любых сбоях, мы создаем CloudWatch Alarm на основе метрики Errors для определенного ресурса Lambda. Точный порог срабатывания сигнала тревоги зависит от того, как часто выполняется задание и его критичность, но чаще всего это значение устанавливается на срабатывание при трех * сбоях за пятиминутный период.

* Один для исходного сбоя плюс две автоматические повторные попытки.

Для некоторых достаточно общих предупреждений такого рода, и уведомления просто направляются на рабочий адрес электронной почты или, возможно, в службу PagerDuty, привязанную к графику дежурства.

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

Наше путешествие, страстный пользователь Lambda, только начинается.

Шаг № 2: С небольшой помощью из темы в соц.сетях + Лямбда-друзей

Вместо того, чтобы отправлять прямо в службу оповещений, мы отправляем оповещения в централизованную тему SNS, которая обрабатывает события сбоев для всех функций Lambda в нашей облачной инфраструктуре данных.

Что происходит с записью о тревоге, отправленной в тему? Конечно, он запускает еще одну лямбда-функцию!

Мы называем эту специальную лямбда-функцию Alerting Lambda, и она выполняет три основных шага:

  1. Отправляет сообщение в Slack с подробностями об ошибке.
  2. Создает инцидент в PagerDuty, также заполняемый полезными деталями.
  3. Запрашивает в CloudWatch Logs сообщения журнала, связанные с ошибкой, и при обнаружении отправляет в Slack.

Первые два шага относительно просты, поэтому мы быстро рассмотрим, как они работают, прежде чем переходить к третьему.

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

Alerting Lambda берет эти данные и анализирует их в очень полезное сообщение Slack (через веб-перехватчик), которое выглядит следующим образом:

Аналогичным образом, используя пакет pypd, мы создаем событие PagerDuty с полезными пользовательскими метриками и заполненной ссылкой на консоль AWS:

Оба эти уведомления помогают нам мгновенно определить, является ли предупреждение законным или, возможно, больше относится к категории «ложных тревог». При управлении более чем 100 задачами это обеспечивает улучшение качества жизни для всех в команде.

Третий шаг Alerting Lambda реализован недавно (вдохновленный этим сообщением об эффективном журналировании Lambda) и оказался излюбленным ярлыком для отладки Lambda.

Результатом является сообщение в Slack, содержащее сообщения журнала о недавних сбоях Lambda, которое выглядит примерно так:

Как именно это работает?

Первый шаг - извлечь имя лямбда-функции из события SNS. Это позволяет нам узнать, к какой группе журналов CloudWatch следует запрашивать недавние ошибки, как показано в фрагменте кода ниже:

И после анализа ответа на запрос для requestId мы запускаем второй запрос Insights, отфильтрованный по этому requestId, переформатируем сообщения журнала, возвращаемые в ответе, и отправляем результаты в Slack.

Поместите такой код в свою Lamba оповещений, и, прежде чем вы это узнаете, вы также будете получать полезные сообщения журнала, отправленные в Slack!

Последние мысли

Хотя это решение оказалось эффективным для наших нужд, его можно улучшить. В частности, когда мы запрашиваем журналы CloudWatch при появлении Lambda Errors, мы не обрабатываем другие сбои Lambda (например, тайм-ауты или регулирование).

Идея выполнить запрос Insights при сбое Lambda не пришла к нам в «Эврика!» момент вдохновения… а скорее от наблюдения за любыми последовательными, предсказуемыми действиями, которые мы выполняем, которые можно автоматизировать. Осведомленность о таких ситуациях поможет любому разработчику в его карьере.

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

Идея развернуть дополнительную тему SNS и Lambda для обработки ошибок была для некоторых отталкивающей. Мы надеемся, что продемонстрировали преимущества преодоления этого ограничивающего мышления. Если вы хотите узнать больше по этой теме, ознакомьтесь с нашим сообщением о безболезненном развертывании лямбда-функций.

И последнее: вам может быть интересно, контролируются ли все остальные лямбда-выражения с помощью лямбда-оповещения, а что тогда контролирует лямбда-функция оповещения?

Хм.