Создание оповещения CloudWatch для метрики Invocations Lambda

Создадим оповещение CloudWatch для метрики Invocations у существующей AWS Lambda и настроим отправку уведомления в SNS. Пошаговая инструкция, рекомендации по порогам, проверке и отладке, а также чек-листы для DevOps и владельцев функций.

В AWS CloudWatch доступно несколько типов метрик для Lambda: метрики вызовов (invocation), метрики производительности (duration, iterator age), и метрики конкурентности (concurrent executions). Метрики вызовов отражают факт выполнения функции и носят бинарный характер (вызов был или не был). Метрики производительности описывают детали отдельного выполнения.

Краткий словарь терминов:

• Invocation — количество запусков кода функции (успешных и неуспешных).
• Error — количество исполнений, завершившихся ошибкой функции или рантайма.
• Throttle — количество вызовов, которые были ограничены квотами (throttled).

Важно: в статье мы создаём оповещение именно на метрику Invocations и настраиваем доставку в SNS. Предполагается, что у вас уже есть AWS аккаунт, Lambda-функция и SNS-топик.

Какие метрики Lambda доступны в CloudWatch

1. Invocations — число запусков кода функции, включая успешные и с ошибками.
2. Errors — число неуспешных запусков, включающее исключения в коде и исключения рантайма.
3. DeadLetterErrors — число неудачных попыток отправки события в Dead Letter Queue (для асинхронных вызовов).
4. DestinationDeliveryFailures — число неудачных доставок в Destination для асинхронных вызовов.
5. Throttles — количество вызовов, которые были ограничены.
6. ProvisionedConcurrencyInvocations — число запусков на provisioned concurrency.
7. ProvisionedConcurrencySpilloverInvocations — число запусков на стандартной concurrency, когда provisioned исчерпан.
8. Duration — время, которое код функции тратит на обработку события.
9. PostRuntimeExtensionsDuration — суммарное время, которое рантайм тратит на выполнение расширений после окончания основного кода функции.
10. IteratorAge — возраст последней записи в событии для event source mapping, читающего из стримов (например, Kinesis).
11. ConcurrentExecutions — текущее число экземпляров Lambda, обрабатывающих события.
12. ProvisionedConcurrentExecutions — число экземпляров, работающих на provisioned concurrency.
13. ProvisionedConcurrencyUtilization — отношение используемых provisioned экземпляров к общему provisioned для версии или алиаса.
14. UnreservedConcurrentExecutions — число событий, обрабатываемых функциями без зарезервированной concurrency.

Нажмите здесь, чтобы узнать больше о метриках Lambda в документации AWS.

Что мы сделаем

1. Войдём в AWS Management Console.
2. Создадим новое оповещение (alarm) для существующей Lambda-функции на метрику Invocations.

Предварительные условия

1. AWS аккаунт.
2. Существующая Lambda-функция.
3. SNS-топик с подпиской (например, email или HTTP endpoint) для получения уведомлений.

Вход в AWS

Найдите и войдите в AWS Management Console. Введите ваши учетные данные и выберите нужный регион.

После успешной авторизации вы попадёте на главную страницу консоли управления.

Пошаговое создание оповещения для Lambda на Invocations

1. В консоли AWS найдите CloudWatch через глобальный поиск.

2. Откройте CloudWatch. В меню слева выберите Alarms.

3. Нажмите Create alarm.

4. Выберите Select metric для указания метрики и условий оповещения.

5. В списке сервисов найдите Lambda и выберите By Function Name.

6. Выберите метрику Invocations для конкретной функции и нажмите Select metric.

7. Укажите Statistic, Threshold type, Alarm condition и Threshold value. В примере мы задали: Sample Count > 1 в течение 5 минут.

Пояснение: Sample Count представляет число точек данных за период. Для Invocations это число вызовов за выбранный период.

8. Настройте действия: укажите, при каком состоянии перехода будет срабатывать оповещение (например, In alarm) и выберите SNS-топик для уведомлений.

9. Добавьте имя и описание оповещения, затем нажмите Next.

10. Проверьте настройки и нажмите Create alarm.

11. После создания оповещение появится в списке Alarms. Его состояние будет обновляться в зависимости от условий.

Рекомендации по выбору условий и порогов

• Выбирайте уровень агрегации (period) в зависимости от частоты вызовов функции. Для функций с высокой частотой лучше использовать меньший период (1 мин), для редких — 5 или 15 мин.
• Если вы хотите отслеживать всплески, используйте Sample Count или Sum. Для средней нагрузки подойдёт Average.
• Чтобы избежать шумных оповещений, комбинируйте порог с количеством периодов, например: > 1 в течение 5 минут (5 периодов по 1 минуте) или > 10 за 5 минут.
• Для функций с provisioned concurrency учитывайте метрики ProvisionedConcurrencyInvocations и ProvisionedConcurrencyUtilization.

Important: одно и то же событие может генерировать несколько метрик. Убедитесь, что вы понимаете, что именно отслеживаете.

Проверка и тестирование оповещения

1. Создайте тестовый вызов Lambda (через консоль или AWS CLI) и посмотрите изменения в CloudWatch Metrics.
2. Проверьте, что оповещение переходит в состояние In alarm и что SNS доставляет сообщение на подписки.
3. Для отладки включите логирование в Lambda (CloudWatch Logs) и проверьте связь между логами и метрикой Invocations.

Подходы и альтернативы

• Альтернатива 1: вместо оповещений CloudWatch можно настроить мониторинг через SaaS-сервисы (Datadog, New Relic). Они могут собирать метрики Lambda и показывать расширенную аналитику.
• Альтернатива 2: использовать CloudWatch Logs Insights для поиска причин увеличения Invocations (например, повторные события, рекурсия).
• Альтернатива 3: для асинхронных ошибок отслеживать DeadLetterErrors и DestinationDeliveryFailures отдельно.

Когда оповещение выдаст ложные срабатывания

• Если внешняя система повторно отправляет события (retries), Invocations вырастет, несмотря на отсутствие проблем в коде.
• Если тестовая нагрузка или CI/CD прогон выполняет многочисленные вызовы. Решение: фильтровать по тэгам/алиасам или временно отключать оповещение.
• Если функция обрабатывает очереди/стримы с переменной задержкой — возможно резкое увеличение IteratorAge без проблем в коде.

Мини-методология для выбора оповещения (шаги)

1. Оцените нормальную частоту вызовов функции (baseline).
2. Определите, какие события важны: всплески, падения до нуля, или превышение нагрузки.
3. Выберите метрику (Invocations, Errors, Throttles и т.д.).
4. Установите порог и число периодов для снижения ложных срабатываний.
5. Настройте канал оповещений (SNS, Lambda healing, PagerDuty).
6. Протестируйте и скорректируйте пороги по итогам 1–2 недель наблюдений.

Чек-лист для ролей

DevOps / SRE:

• Убедиться, что CloudWatch имеет выбранный период агрегации.
• Настроить SNS с нужными подписками.
• Добавить runbook для автоматических действий при срабатывании.

Разработчик функции:

• Проверить, что логирование достаточное для поиска причины увеличения Invocations.
• Добавить метрики пользовательского уровня при необходимости.

Владелец сервиса:

• Согласовать пороги оповещений и каналы доставки.
• Проверить реакцию команды на оповещение.

Playbook при срабатывании оповещения

1. Получено уведомление в SNS. Откройте CloudWatch Alarm и проверьте состояние и последние данные метрики.
2. Проверьте CloudWatch Logs для соответствующей функции: найдите временные метки вызовов.
3. Определите источник повышенной нагрузки: тесты, пиковая активность пользователей, системные ретраи.
4. Если вызовов слишком много и это нагрузка, примените throttling или масштабирование (если возможно).
5. Если причина — ошибка или петля вызовов, откатите недавние изменения или приостановите источник событий.
6. После исправления подтвердите, что метрика вернулась к норме, и закройте инцидент.

Критерии приёмки

• Оповещение создано и видно в списке Alarms.
• При тестовом триггере Alarm переходит в состояние In alarm и SNS доставляет сообщение на подписки.
• Оповещение не генерирует ложных алертов в течение 24–48 часов нормальной рабочей нагрузки.

Отладка и распространённые проблемы

Проблема: оповещение не срабатывает при явном увеличении вызовов.

• Проверьте регион (CloudWatch и Lambda в одном регионе).
• Убедитесь, что выбрана правильная метрика (By Function Name) и имя функции.
• Проверьте период и статистику. Возможно, вы смотрите усреднённую метрику.

Проблема: SNS не доставляет уведомления.

• Проверьте подписки SNS, подтвердите email/endpoint.
• Посмотрите CloudWatch Logs для DeliveryFailure сообщений.

Проблема: слишком много ложных алертов.

• Увеличьте количество периодов для проверки (например, 3 из 5).
• Используйте более высокий порог или переключитесь на суммарную метрику (Sum) вместо Sample Count.

Модель принятия решений (Mermaid)

flowchart TD
  A[Начало: заметен рост Invocations] --> B{Это ожидаемый трафик?}
  B -- Да --> C[Наблюдать и документировать]
  B -- Нет --> D{Есть ошибки или throttles?}
  D -- Да --> E[Проверить логи, исправить код/исходник событий]
  D -- Нет --> F[Проверить источники событий и конфигурацию инфраструктуры]
  E --> G[Восстановление и мониторинг]
  F --> G
  C --> G
  G --> H[Закрыть инцидент]

Шаблон заметок по оповещению (кратко)

• Имя оповещения: lambda-invocations-
• Регион: eu-central-1 (пример)
• Метрика: Lambda > By Function Name > Invocations
• Статистика: Sample Count
• Порог: > 1
• Периоды: 5 минут (5×1min) или 1×5min
• Действие: SNS topic arn:aws:sns:… -> email/pager

Безопасность и приватность

Оповещения и метрики не передают содержимое событий Lambda, только количественные показатели. Убедитесь, что в логах и в уведомлениях не содержится чувствительных данных. Контролируйте доступ к консоли CloudWatch и SNS через IAM-политики.

Заключение

Мы создали оповещение CloudWatch по метрике Invocations для Lambda и настроили отправку уведомлений в SNS. Вы получили: пошаговую инструкцию, рекомендации по выбору порогов, чек-листы для ролей, playbook для реагирования и советы по отладке. Используйте те же шаги для создания оповещений по другим метрикам (Errors, Throttles, Duration и т.д.).

Summary

• Оповещение должно соответствовать типичной частоте вызовов функции.
• Тестируйте оповещения через пробные вызовы и проверяйте доставку SNS.
• Корректируйте пороги и периоды, чтобы снизить шум.

Notes

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