Тестирование сигналов тревоги AWS Cloudwatch

TL;DR: как проверить, правильно ли работают ваши будильники!

Мотивация

AWS CloudWatch — облачный сервис для хранения и индексации любых журналов. Вы можете добавить размеры, свойства,…

С помощью AWS CloudWatch Insight мы можем определять метрики в журналах, отправлять встроенные метрики… и создавать оповещения!

Наличие сигнализации для вашего обслуживания является обязательным в настоящее время.

Язык спецификации для определения метрик и сигналов тревоги может быть немного сложным.

Дело в том, что когда у вас есть правильный синтаксис для вашей метрики и/или сигнала тревоги, сразу же возникает вопрос: как я могу его протестировать?

Давай увидим это!

AWS CLI для спасения

Если вы привыкли использовать AWS, вы, вероятно, установили инструмент aws CLI.

В разделе cloudwatch мы нашли команды и параметры для управления всем жизненным циклом метрик и сигналов тревоги.

Если вы еще не установили его, вы можете установить его с помощью следующей команды оболочки

Mac OS X

$ brew install awscli

GNU/Linux

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ unzip awscliv2.zip
$ sudo ./aws/install

Пример

Мы используем очень распространенный сценарий: лямбда-функцию.

Использовать формат AWS SAM очень просто.

Наша функция — это файл pdf2png. Он получает файл PDF, отображает его как изображение и сохраняет в S3 как изображение PNG.

В этом примере мы определяем две метрики:

Ошибка, когда файл PDF недействителен.
Время обработки одного файла

По этим показателям мы определяем следующие сигналы тревоги

Количество ошибок PDF превышает пороговое значение
Среднее время обработки превышает пороговое значение

Определение тревог в SAM

Как вы, наверное, знаете, Serveless Application Model, также известная как SAM, — это еще один инструмент AWS для управления бессерверными ресурсами AWS.

Если вы когда-то создавали лямбда-функцию, вы, скорее всего, использовали ее.

Сам лямбда-код выходит за рамки. Сосредоточимся на сигналах тревоги.

Код

Мы используем SAM для создания и развертывания нашего кода.

Это наш template.yaml за это.

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

Первый касается количества обработанных PDF-файлов с ошибкой. Этот сигнал срабатывает, когда за последний час (3600 секунд) 5 или более PDF-файлов обрабатываются с ошибкой.

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

Для применения вызываем следующие команды

$ sam build
$ sam deploy --guided

Параметр guided необходим только для первого развертывания. Он определяет такие вещи, как имя стека CloudFormation, политики отката и т. д.

Если все работает хорошо, результат должен быть похож на следующий.

Получить статус тревоги

Любой сигнал тревоги CloudWatch имеет состояние «INSUFFICIENT_DATA» сразу после его создания. С помощью команды cloudwatch describe-alarms мы можем увидеть его состояние и другие детали.

$ aws cloudwatch describe-alarms --region eu-west-1 --alarm-names pdf-converter-files-error
{
    "MetricAlarms": [
        {
            "ComparisonOperator": "GreaterThanOrEqualToThreshold",
            "StateReason": "Unchecked: Initial alarm creation",
            "InsufficientDataActions": [],
            "AlarmName": "pdf-converter-files-error",
            "StateValue": "INSUFFICIENT_DATA",
            "ActionsEnabled": true,
            "AlarmDescription": "Number of errors in processed PDF files pass the threshold in one hour",
            "Dimensions": [],
            "AlarmActions": [],
            "Threshold": 5.0,
            "TreatMissingData": "missing",
            "OKActions": [],
            "EvaluationPeriods": 1,
            "Namespace": "pdf-converter",
            "Statistic": "Sum",
            "Period": 3600,
            "AlarmConfigurationUpdatedTimestamp": "2022-10-06T09:29:58.012Z",
            "MetricName": "error-pdf-file",
            "AlarmArn": "arn:aws:cloudwatch:eu-west-1:520766964441:alarm:pdf-converter-files-error",
            "StateUpdatedTimestamp": "2022-10-06T09:29:58.012Z"
        }
    ]
}

Как вводить поддельные метрики

Внутри параметров CloudWatch есть команда, которая позволяет нам вводить метрические данные. Мы используем его для ввода «фальшивых» данных и смотрим, меняет ли тревога свое состояние.

Эта подкоманда put-metric-data .

Обязательные параметры: namespace , metric-name , value и, во многих случаях, unit.

Для проверки аларма о среднем времени обработки PDF-файлов в разных вызовах вводим следующие данные:

$ aws cloudwatch put-metric-data --namespace pdf-converter --metric-name pdf-processing-time --value 1200  --unit Milliseconds
$ aws cloudwatch put-metric-data --namespace pdf-converter --metric-name pdf-processing-time --value 4300  --unit Milliseconds
$ aws cloudwatch put-metric-data --namespace pdf-converter --metric-name pdf-processing-time --value 2300  --unit Milliseconds
$ aws cloudwatch put-metric-data --namespace pdf-converter --metric-name pdf-processing-time --value 6300  --unit Milliseconds

Если мы теперь проверим статус тревоги,

$ aws cloudwatch describe-alarms
{
            "AlarmName": "pdf-converter-TotalPDFProcessingTimeAlarm-FX2TV7R36S0T",
            "AlarmArn": "arn:aws:cloudwatch:eu-west-1:520766964441:alarm:pdf-converter-TotalPDFProcessingTimeAlarm-FX2TV7R36S0T",
            "AlarmDescription": "Average processing time exceeds threshold",
            "AlarmConfigurationUpdatedTimestamp": "2022-10-09T09:36:56.511Z",
            "ActionsEnabled": true,
            "OKActions": [],
            "AlarmActions": [],
            "InsufficientDataActions": [],
            "StateValue": "OK",
            "StateReason": "Threshold Crossed: 1 datapoint [1200.0 (08/10/22 09:39:00)] was not greater than or equal to the threshold (15000.0).",
            "StateReasonData": "{\"version\":\"1.0\",\"queryDate\":\"2022-10-09T09:39:13.827+0000\",\"startDate\":\"2022-10-08T09:39:00.000+0000\",\"unit\":\"Milliseconds\",\"statistic\":\"Average\",\"period\":86400,\"recentDatapoints\":[1200.0],\"threshold\":15000.0,\"evaluatedDatapoints\":[{\"timestamp\":\"2022-10-08T09:39:00.000+0000\",\"sampleCount\":1.0,\"value\":1200.0}]}",
            "StateUpdatedTimestamp": "2022-10-09T09:39:13.829Z",
            "MetricName": "pdf-processing-time",
            "Namespace": "pdf-converter",
            "Statistic": "Average",
            "Dimensions": [],
            "Period": 86400,
            "Unit": "Milliseconds",
            "EvaluationPeriods": 1,
            "Threshold": 15000.0,
            "ComparisonOperator": "GreaterThanOrEqualToThreshold"
}

Все в порядке… идем запускать.

$ aws cloudwatch put-metric-data --namespace pdf-converter --metric-name pdf-processing-time --value 61300  --unit Milliseconds
$ aws cloudwatch put-metric-data --namespace pdf-converter --metric-name pdf-processing-time --value 161300  --unit Milliseconds
$ aws cloudwatch put-metric-data --namespace pdf-converter --metric-name pdf-processing-time --value 13300  --unit Milliseconds

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

$ aws cloudwatch set-alarm-state --alarm-name processing-time-exceeds-alarm --state-value "INSUFFICIENT_DATA" --state-reason "manual testing"

…и Бинго!

$ aws cloudwatch describe-alarms
{
    "MetricAlarms": [
        {
            "AlarmName": "pdf-converter-TotalPDFProcessingTimeAlarm-FX2TV7R36S0T",
            "AlarmArn": "arn:aws:cloudwatch:eu-west-1:520766964441:alarm:pdf-converter-TotalPDFProcessingTimeAlarm-FX2TV7R36S0T",
            "AlarmDescription": "Average processing time exceeds threshold",
            "AlarmConfigurationUpdatedTimestamp": "2022-10-09T09:36:56.511Z",
            "ActionsEnabled": true,
            "OKActions": [],
            "AlarmActions": [],
            "InsufficientDataActions": [],
            "StateValue": "ALARM",
            "StateReason": "Threshold Crossed: 1 datapoint [35714.28571428572 (08/10/22 09:47:00)] was greater than or equal to the threshold (15000.0).",
            "StateReasonData": "{\"version\":\"1.0\",\"queryDate\":\"2022-10-09T09:47:13.813+0000\",\"startDate\":\"2022-10-08T09:47:00.000+0000\",\"unit\":\"Milliseconds\",\"statistic\":\"Average\",\"period\":86400,\"recentDatapoints\":[35714.28571428572],\"threshold\":15000.0,\"evaluatedDatapoints\":[{\"timestamp\":\"2022-10-08T09:47:00.000+0000\",\"sampleCount\":7.0,\"value\":35714.28571428572}]}",
            "StateUpdatedTimestamp": "2022-10-09T09:47:13.815Z",
            "MetricName": "pdf-processing-time",
            "Namespace": "pdf-converter",
            "Statistic": "Average",
            "Dimensions": [],
            "Period": 86400,
            "Unit": "Milliseconds",
            "EvaluationPeriods": 1,
            "Threshold": 15000.0,
            "ComparisonOperator": "GreaterThanOrEqualToThreshold"
        }
    ],
    "CompositeAlarms": []
}

Если мы зайдем в консоль AWS Cloudwatch, мы также увидим уведомление о тревоге.

Заключение

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

Между тем, благодаря CLI мы можем выполнять некоторые базовые тесты.