Работа с оповещением на основе метрик для AWS Lambda

Первоначально опубликовано в блоге Dashbird.

Традиционно в “белом ящике” мониторинга отчет об ошибках достигается с помощью сторонних библиотек, которые улавливают и сообщают о сбоях внешним сервисам и уведомляют разработчиков при возникновении проблемы. Я утверждаю, что для управляемых сервисов этого можно достичь с меньшими усилиями, без агентов и без накладных расходов на производительность.

На самом деле, есть много причин, по которым не стоит использовать классические инструменты отчетов об ошибках в AWS Lambda. Наиболее важной из них является то, что библиотеки обработки ошибок в коде слепы к специфическим для Lambda сбоям, таким как таймауты, неправильно сконфигурированные пакеты и сбои из-за отсутствия памяти. Кроме того, существует проблема с охватом – реализация отчетов об ошибках для каждой функции – это большой объем работы. Всякий раз, когда вы добавляете сервис в свою инфраструктуру, вы должны пройти через настройку отслеживания ошибок и мониторинга для него, и забыв сделать это, вы можете получить “слепые пятна” в вашей системе.

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

О слове “наблюдаемость”

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

Помимо журналов CloudWatch, мы можем использовать API AWS для обнаружения ресурсов и рентгена, а также CloudTrail для трассировки и соединения потоков выполнения.

Мы можем сделать обнаружение сбоев лучше уже сегодня

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

Давайте разберемся

Единственным условием для обнаружения ошибок на основе журналов и видимости в целом является то, что журналы отправляются в CloudWatch (в большинстве случаев это делается по умолчанию). Оттуда мы можем выполнять интеллектуальное сопоставление шаблонов и дедукцию для обнаружения сценариев сбоев.

Кроме того, журналы содержат множество других данных, которые указывают на задержки и использование памяти, а также позволяют нам связывать запросы с AWS X-ray и искать отчет о трассировке конкретного запроса. Все это позволяет нам собрать много контекста, чтобы понять, что пошло не так в конкретном случае.

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

Заключение

С появлением управляемых и распределенных сервисов ландшафт мониторинга должен претерпеть значительные изменения, чтобы идти в ногу с современными облачными приложениями. В настоящее время накладные расходы на devops являются одним из самых больших препятствий для компаний, желающих использовать serverless в production и полагаться на него для критически важных приложений. Наша команда в Dashbird надеется решить эту проблему за один раз.

---

Настройка *Dashbird занимает около 5 минут, после чего вы получите полную видимость ваших бессерверных приложений. Попробуйте, зарегистрировавшись здесь.* Фраза “лучше перестраховаться, чем потом жалеть” звучит всякий раз, когда люди говорят о мониторинге или получении наблюдаемости ваших ресурсов AWS, но правда в том, что вы не можете сидеть и ждать, пока возникнет проблема, вам нужно активно искать возможности для улучшения вашего приложения, чтобы оставаться на шаг впереди конкурентов. Настройка оповещений, которые срабатывают всякий раз, когда происходит определенное событие, – отличный способ следить за тем, что происходит за кулисами ваших бессерверных приложений, и именно об этом я хотел бы рассказать в этой статье.

Метрики AWS Lambda

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

И если Cloudwatch – хороший инструмент для получения метрик ваших функций, то Dashbird поднимает его на ступень выше, предоставляя то недостающее звено, которое необходимо для правильной отладки этих досадных проблем с Lambda. Он позволяет обнаруживать любые виды сбоев на всех языках программирования, поддерживаемых платформой. Сюда входят сбои, ошибки конфигурации, таймауты, ранние выходы и т.д. Еще одна очень ценная вещь, которую предлагает Dashbird, – это Error Aggregation, позволяющая видеть мгновенные метрики об ошибках, использовании памяти, продолжительности, вызовах, а также выполнении кода.

Метрики AWS Lambda с пояснениями

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

Далее мы рассмотрим некоторые метрики пространства имен внутри AWS Lambda и объясним, как они работают. Например

Invocations подсчитает количество раз, когда функция была вызвана в ответ на вызов API invocation или на событие, которое заменяет метрику RequestCount. Все это включает успешные и неудачные вызовы, но не включает дросселированные попытки. Следует отметить, что AWS Lambda будет отправлять упомянутые метрики в CloudWatch только в том случае, если их значение находится в точке ненулевого значения.

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

Есть ограничения, о которых мы должны упомянуть:

• Не учитывает вызовы, которые были неудачными из-за того, что количество вызовов превысило установленный по умолчанию лимит одновременных вызовов (код ошибки 429).
• Не учитываются сбои, произошедшие из-за внутренних ошибок сервиса (код ошибки 500).

DeadLetterErrors могут начать дискретный рост числа, когда Lambda не может записать событие о неудачной полезной нагрузке в предварительно настроенные строки DeadLetter. Это может произойти из-за ошибок разрешения, неправильно настроенных ресурсов, тайм-аутов или даже из-за дросселей от нижележащих сервисов.

Продолжительность измеряется в реальном времени, начиная с момента, когда код функции начинает выполняться в результате вызова, и до момента прекращения выполнения. Для выставления счетов длительность округляется до ближайших 100 миллисекунд. Примечательно, что AWS Lambda отправляет эти метрики в CloudWatch, только если значение ненулевое.

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

Iterator Age используется только для потоковых вызовов. Эти функции вызываются одним из двух потоков: DynamoDB или поток Kinesis от Amazon. Измеряет возраст последней записи для каждой обрабатываемой партии записей. Возраст – это единственная разница между временем, когда Lambda получает пакет, и временем, когда последняя запись из пакета была записана в поток.

Concurrent Executions – это совокупная метрическая система для всех функций внутри аккаунта, а также для всех других функций с предварительно установленным лимитом одновременности. Одновременное выполнение не применимо для различных форм и версий функций. По сути, это означает, что измеряется сумма одновременных выполнений в конкретной функции с определенного момента времени. Очень важно, чтобы этот показатель рассматривался как средняя метрика, поскольку он агрегирован по периоду времени.

Unreserved Concurrent Executions – это почти то же самое, что и Concurrent Executions, но они представляют собой сумму параллелизма функций, для которых не установлены пользовательские ограничения на количество одновременных операций. Они относятся только к учетной записи пользователя, и их нужно рассматривать как среднюю метрику, если они агрегируются за период времени.

С чего начать?

Cloudwatch

Чтобы получить доступ к метрикам с помощью консоли CloudWatch, необходимо открыть консоль и в навигационной панели выбрать опцию метрики. Далее, в панели CloudWatch Metrics by Category, необходимо выбрать опцию Lambda Metrics.

Dashbird

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

Настройка оповещений на основе метрик для лямбда-функций

Очень важно настроить сигналы тревоги, которые будут уведомлять вас, когда ваша Lambda-функция завершается с ошибкой, чтобы вы могли квалифицированно отреагировать.

Cloudwatch

Чтобы настроить тревогу для неработающей функции (причиной может быть падение всего сайта или даже ошибка в коде), необходимо зайти в консоль CloudWatch, выбрать Alarms слева и нажать Create Alarm. Выберите “Lambda Metrics”, а затем найдите в списке имя вашей Lambda. Оттуда установите флажок в строке, где имя метрики – “Error”. Затем просто нажмите кнопку Next.

Теперь вы сможете задать имя и описание для сигнала тревоги. Отсюда вы должны настроить сигнал тревоги на срабатывание каждый раз, когда “Ошибки” превышают 0 в течение одного непрерывного периода. В качестве Статистики в выпадающем окне “Период” выберите “сумму” и минуты, необходимые для вашего конкретного случая.

В окне “Уведомление” в выпадающем меню выберите “выбрать список уведомлений” и выберите конечную точку SNS. Последним шагом в этой настройке является нажатие кнопки “Создать тревогу”.

Dashbird

Настройка оповещений на основе метрик с помощью Dashbird не так сложна, даже наоборот. Находясь в приложении, перейдите в меню “Оповещения”, нажмите на кнопку “Добавить” в правой части экрана и дайте ему имя. После этого вы выбираете интересующую вас метрику, которая может быть холодным стартом, повторной попыткой, вызовом и, конечно, ошибкой. Остается только выбрать правила (например: когда количество холодных запусков превысит 5 в течение 10 минут, предупредить меня), и все готово.

Как выбрать правильное решение для оповещений на основе метрик?

Сложный вопрос. Cloudwatch – отличный инструмент, но как только в вашей системе появится больше лямбд, вам будет очень сложно отлаживать или даже понимать ошибки из-за большого объема информации. Dashbird, с другой стороны, предлагает подробную информацию о ваших вызовах и ошибках, которая проста и лаконична, и имеет гораздо больше гибкости, когда дело доходит до настройки. Мой коллега Ренато составил простую таблицу, в которой сравниваются эти два сервиса.

Не могу не сделать замечание: в AWS CloudWatch при каждом вызове функции создается микроконтейнер для обслуживания запроса и для него открывается поток журнала в CloudWatch. Они повторно используют один и тот же поток журнала до тех пор, пока этот контейнер остается живым. Это означает, что один и тот же поток журналов получает журналы от нескольких обращений в одном месте.

Это быстро становится очень беспорядочным и затрудняет отладку проблем, потому что вам нужно открыть последний поток журналов и просмотреть все журналы последних вызовов. В то время как в Dashbird мы показываем отдельные вызовы, упорядоченные по времени, что значительно облегчает разработчикам понимание того, что происходит в любой момент времени. Фраза “лучше перестраховаться, чем потом жалеть” звучит всякий раз, когда люди говорят о мониторинге или обеспечении наблюдаемости ваших ресурсов AWS, но правда в том, что вы не можете сидеть и ждать, пока возникнет проблема, вам нужно активно искать возможности для улучшения вашего приложения, чтобы оставаться на шаг впереди конкурентов. Настройка оповещений, которые срабатывают всякий раз, когда происходит определенное событие, – отличный способ следить за тем, что происходит за кулисами ваших бессерверных приложений, и именно об этом я хотел бы рассказать в этой статье.

Метрики AWS Lambda

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

И если Cloudwatch является хорошим инструментом для получения метрик ваших функций, то Dashbird поднимает его на ступень выше, предоставляя то недостающее звено, которое необходимо для правильной отладки этих досадных проблем с Lambda. Он позволяет обнаруживать любые виды сбоев на всех языках программирования, поддерживаемых платформой. Сюда входят сбои, ошибки конфигурации, таймауты, ранние выходы и т.д. Еще одна весьма ценная вещь, которую предлагает Dashbird, – это Error Aggregation, позволяющая видеть мгновенные метрики об ошибках, использовании памяти, продолжительности, вызовах, а также выполнении кода.

Метрики AWS Lambda с пояснениями

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

Далее мы рассмотрим некоторые метрики пространства имен внутри AWS Lambda и объясним, как они работают. Например

Invocations подсчитывает количество раз, когда функция была вызвана в ответ на вызов API invocation или на событие, которое заменяет метрику RequestCount. Все это включает успешные и неудачные вызовы, но не включает дросселированные попытки. Следует отметить, что AWS Lambda будет отправлять упомянутые метрики в CloudWatch только в том случае, если их значение находится в точке ненулевого значения.

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

Есть ограничения, о которых мы должны упомянуть:

• Не учитывает вызовы, которые были неудачными из-за того, что количество вызовов превысило установленный по умолчанию лимит одновременных вызовов (код ошибки 429).
• Не учитываются сбои, произошедшие из-за внутренних ошибок сервиса (код ошибки 500).

DeadLetterErrors могут начать дискретный рост числа, когда Lambda не может записать событие о неудачной полезной нагрузке в предварительно настроенные строки DeadLetter. Это может произойти из-за ошибок разрешения, неправильно настроенных ресурсов, тайм-аутов или даже из-за дросселей от нижестоящих сервисов.

Продолжительность измеряется в реальном времени, начиная с момента, когда код функции начинает выполняться в результате вызова, и до момента прекращения выполнения. Для выставления счетов длительность округляется до ближайших 100 миллисекунд. Примечательно, что AWS Lambda отправляет эти метрики в CloudWatch, только если значение ненулевое.

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

Iterator Age используется только для потоковых вызовов. Эти функции вызываются одним из двух потоков: DynamoDB или поток Kinesis от Amazon. Измеряет возраст последней записи для каждой обрабатываемой партии записей. Возраст – это единственная разница между временем, когда Lambda получает пакет, и временем, когда последняя запись из пакета была записана в поток.

Concurrent Executions – это совокупная метрическая система для всех функций внутри аккаунта, а также для всех других функций с предварительно установленным лимитом одновременности. Одновременное выполнение не применимо для различных форм и версий функций. По сути, это означает, что измеряется сумма одновременных выполнений в конкретной функции с определенного момента времени. Очень важно, чтобы этот показатель рассматривался как средняя метрика, поскольку он агрегирован по периоду времени.

Unreserved Concurrent Executions – это почти то же самое, что и Concurrent Executions, но они представляют собой сумму параллелизма функций, для которых не установлены пользовательские ограничения на количество одновременных операций. Они применяются только к учетной записи пользователя, и их нужно рассматривать как среднюю метрику, если они агрегируются за период времени.

С чего начать?

Cloudwatch

Чтобы получить доступ к метрикам с помощью консоли CloudWatch, необходимо открыть консоль и в навигационной панели выбрать опцию метрики. Далее, в панели CloudWatch Metrics by Category, необходимо выбрать опцию Lambda Metrics.

Dashbird

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

Настройка оповещений на основе метрик для лямбда-функций

Очень важно настроить сигналы тревоги, которые будут уведомлять вас, когда ваша Lambda-функция завершает работу с ошибкой, чтобы вы могли квалифицированно отреагировать.

Cloudwatch

Чтобы настроить оповещение о неудачной функции (причиной может быть падение всего сайта или даже ошибка в коде), необходимо перейти в консоль CloudWatch, слева выбрать Alarms и нажать Create Alarm. Выберите “Lambda Metrics”, а затем найдите в списке имя вашей Lambda. Оттуда установите флажок в строке, где имя метрики – “Error”. Затем просто нажмите кнопку Next.

Теперь вы сможете задать имя и описание для сигнала тревоги. Отсюда вы должны настроить сигнал тревоги на срабатывание каждый раз, когда “Ошибки” превышают 0 в течение одного непрерывного периода. В качестве Статистики в выпадающем окне “Период” выберите “сумму” и минуты, необходимые для вашего конкретного случая.

В окне “Уведомление” в выпадающем меню выберите “выбрать список уведомлений” и выберите конечную точку SNS. Последним шагом в этой настройке является нажатие кнопки “Создать тревогу”.

Dashbird

Настройка оповещений на основе метрик в Dashbird не так сложна, даже наоборот. Находясь в приложении, перейдите в меню “Оповещения”, нажмите на кнопку добавления в правой части экрана и дайте ему имя. После этого вы выбираете интересующую вас метрику, которая может быть холодным стартом, повторной попыткой, вызовом и, конечно, ошибкой. Остается только выбрать правила (например: когда количество холодных запусков превысит 5 в течение 10 минут, предупредить меня), и все готово.

Как выбрать правильное решение для оповещений на основе метрик?

Сложный вопрос. Cloudwatch – отличный инструмент, но как только в вашей системе появится больше лямбд, вам будет очень сложно отлаживать или даже понимать ошибки из-за большого объема информации. Dashbird, с другой стороны, предлагает подробную информацию о ваших вызовах и ошибках, которая проста и лаконична, и имеет гораздо больше гибкости, когда дело доходит до настройки. Мой коллега Ренато составил простую таблицу, в которой сравниваются эти два сервиса.

Не могу не сделать замечание: в AWS CloudWatch при каждом вызове функции создается микроконтейнер для обслуживания запроса и для него открывается поток журнала в CloudWatch. Они повторно используют один и тот же поток журнала до тех пор, пока этот контейнер остается живым. Это означает, что один и тот же поток журналов получает журналы от нескольких вызовов в одном месте.

Это быстро становится очень беспорядочным и затрудняет отладку проблем, поскольку вам нужно открыть последний поток журналов и просмотреть все журналы последних вызовов. В то время как в Dashbird мы показываем отдельные вызовы, упорядоченные по времени, что значительно облегчает разработчикам понимание того, что происходит в любой момент времени.