Блог Amazon Web Services

Как мониторить состояние AWS инфраструктуры и вовремя получать важные алерты через Corezoid Process Engine?

Денис Баталов, архитектор AWS, @dbatalov
Друзья, рад представить вам гостевой пост от коллег из ПриватБанка (Украина) — 13-ого по величине банка в Восточной Европе. Из более чем 25 миллионов клиентов банка, 10 миллионов регулярно пользуются онлайн платформой Приват24, и более 5,5 миллионов пользуются его мобильной версией.

Недавно ПриватБанк заменил многие из своих систем обработки бизнес-логики на гибкий облачный бэкенд названный Corezoid и созданный отделом R&D банка. В Corezoid всё построено на основе API, а сам он работает на AWS. ПриватБанк также запустил Sender — мобильный мессенджер для бизнеса, который позволяет ПриватБанку общаться со своими клиентами, а также клиентам — общаться с другими компаниями предоставляющими услуги. Sender спроектирован с учётом мобильного образа жизни, а его функционал реализован на основе Corezoid. В нашем посте речь пойдёт об интересном примере использования Corezoid для мониторинга состояния инфраструктуры AWS. Далее текст коллеги из ПриватБанка.

Павел Шахман, руководитель команды DevOps, Corezoid
Для полного контроля за всеми изменениями в вашей AWS инфраструктуре есть замечательный веб-сервис CloudTrail.

С помощью CloudTrail можно получить историю вызовов API AWS, сделанных в вашем аккаунте, включая вызовы API, сделанные из Консоли управления AWS или с помощью пакетов AWS SDK, инструментов командной строки и сервисов AWS более высокого уровня (таких как AWS CloudFormation). История вызовов API AWS в CloudTrail делает возможным проведение анализа безопасности, отслеживание изменения ресурсов и аудит соответствия, т.к. включает в себя идентификацию источника, совершившего вызов API, время вызова API, IP-адрес источника, совершившего вызов API, параметры запроса, а также элементы ответа, возвращенные сервисом AWS.

С полным списком поддерживаемых в CloudTrail сервисов можно ознакомиться в документации.

В этой статье мы расскажем, как легко и быстро настроить уведомления о важных событиях в работе AWS инфраструктуры.

Для получения событий из CloudTrail есть два основных пути:

  • доставка лог файлов в определенную корзину (Amazon S3)
  • доставка событий в указанную лог-группу (CloudWatch Logs)

В первом случае рекомендуется настроить уведомление в SNS-топик о появлении нового файла, а во втором случае уже можно задействовать фильтры в CloudWatch Logs.

При попадании событий в лог-группу на них можно применить различные пользовательские фильтры и связать их с CloudWatch Alarms, создав Alarm на каждый из них, для получения уведомлений, например всё в тот же SNS-топик.

Настроить начальный набор фильтров достаточно легко — для этого можно использовать любезно предоставленный компанией AWS шаблон ☺.

Если загрузить его в AWS CloudFormation Designer, то можно хоть как-то визуализировать создаваемые проверки, их взаимосвязи и в дальнейшем модифицировать этот шаблон, применяя обновления стека после каждой модификации.

При срабатывании какого-либо фильтра, например на изменение Security Group, вы получите через SNS-топик сообщение:

Кроме этого можно получить доступ ко всем событиям CloudTrail используя AWS Console и, оперируя заданным набором фильтров, можно просматривать события через веб-интерфейс.

Но заглядывать каждый раз в табличку и вручную что-то искать не очень удобно. Дальше мы расскажем как можно облегчить себе задачу по поддержке существующего набора фильтров, быстрому добавлению новой логики и визуализации. Как настроить отправление уведомлений в любой удобный канал коммуникации, где ответственному сотруднику удобно читать такие сообщения: мессенджер, е-майл или, к примеру, Slack.
В нашем случае для получения уведомлений мы используем мобильный мессенджер Sender (Sender.mobi).

Сервис CloudTrail сохраняет информацию о событии в течение 15 минут после вызова API и отправляет файлы логов в корзину примерно через каждые пять минут. Таким образом нужно учитывать, что задержка между временем события и уведомлением может быть до 20 мин. Если файлы с архивами не появляются в корзине — проверьте ее политику, возможно при редактировании допущена ошибка и CloudTrail не может сохранить файл.

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

Для написания функций Lambda в AWS можно использовать Python, Node.js, Java. Нашу функцию мы написали на Python.

Она связана триггером с S3 корзиной и срабатывает по событию типа ObjectCreatedByPut: достает файл, распаковывает и отправляет массив событий (events) через API в наш Corezoid Process Engine. Эта функция срабатывает на каждый PUT файла в корзину: достает файл, распаковывает и отправляет массив событий (events) через API в наш Corezoid Process Engine.

Corezoid Process Engine — это наша собственная технология, доступная по адресу Corezoid.com, а также в Amazon Marketplace.

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

Вот список логик, которые доступны в Corezoid:

Название Описание
Task
Counter (Alert when there is tasks queue) 		Используется для запуска/закрытия эскалации по количеству задач в узле. Например, пусть необходимо реагировать на разное количество задач в очереди, которые требуют обработки. Если количество объектов в очереди превышает:

  • 50 – уведомляем менеджера;
  • 100 – уведомляем руководителя менеджера.

При снижении количества объектов в очереди мы сможем уведомить менеджера/руководителя о уменьшении количества необработанных задач
Time
limit (Limit the time of the task in the node)		 Если время нахождение задачи в узле превышает предельное время, то задача переводится в целевой узел
Go Задача безусловно переводится в целевой узел. Является последней командой в программе обработки
Condition Условие является конъюнкцией сравнений значений параметров задачи с константами. Если условие выполнено, то задача переводится в целевой узел
API
Call		 Синхронный вызов метода внешнего API в форматах JSON, XML, SOAP. Задача зависает в узле, пока метод API выполняется
Waiting
for callback		 Синхронизация с внешним процессом. Задача зависает в узле, пока не придет ответ от внешнего процесса
Code Интерпретируется фрагмент кода на указанном языке (Java Script или Erlang). Доступ к параметрам задачи – через переменную data
Copy
task		 Задача, возможно, частично копируется в начальный узел другого процесса
Modify
task		 Задача, возможно, частично модифицируется, если находится в узле Waiting for callback или Set state
Call
process		 Задача, возможно, частично копируется в начальный узел другого процесса, тем самым вызывается обработка этой задачи другим процессом. Когда обработка закончена, вызванный процесс должен вернуть обработанную задачу командой Reply
to process
Reply
to process 		Задача возвращается вызвавшему процессу. Идентификатор процесса хранится в самой задаче
Sum Суммируются значения некоторых параметров задачи
Set
parameter		 Присваивается значение параметру задачи
Queue Текущая задача переводится в локальное хранилище. При этом хранилище может работать в одном из двух режимов: в режиме очереди (FIFO = First In First Out) или в режиме стека (LIFO = Last In First Out). Задача находится в хранилище, пока не
поступит сигнал
Get
task from queue
Get
task from queue 		Из очереди в указанном процессе и в указанном узле извлекается задача для обработки
Delay Обработка задачи приостанавливается на указанное время

Используя эти логические блоки мы настроим отправку уведомлений для Non-API событий:

  • попытки входа в AWS аккаунт;
  • создание\удаление spot-инстансов.

Логика в Corezoid

Построим небольшой проект, состоящий из процесса-маршрутизатора и процессов для обработки 2-х основных типов событий CloudTrail: API вызовов и Non-API events.
Первым делом, создаем папку, три новых процесса в Corezoid и настраиваем соответствующие узлы.

Для безопасной передачи данных в Corezoid создадим API-пользователя и сохраним его login, secret key и process id процесса-маршрутизатора — эти данные понадобятся для настройки нашей функции Lambda.
API пользователю мы разрешим отправлять заявки в настройках папки с процессами:

  • В начале обработки в зависимости от аккаунта (логика Condition) мы заменяем числовой идентификатор на любой удобный алиас (например, логика Set Parameter -> AccountAlias == “Corezoid Demo” и т.д.).
  • В узле “Route by Event Type” мы в зависимости от типа события отправляем его на обработку в процесс Api Events или Non-Api Events.

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

{ "eventVersion": "1.04", "eventID": "bbf878c3-7138-4207-929d-5b4b1450fea8", "eventTime": "2016-10-02T17:51:36Z", "additionalEventData": { "MobileVersion": "No", "LoginTo": "https://console.aws.amazon.com/console/home?state=hashArgs%23&isauthcode=true", "MFAUsed": "No" }, "recipientAccountId": "\"Corezoid Dev\"", "requestParameters": null, "eventType": "AwsConsoleSignIn", "errorMessage": "Failed authentication", "responseElements": { "ConsoleLogin": "Failure" }, "awsRegion": "us-east-1", "eventName": "ConsoleLogin", "userIdentity": { "accountId": "111111111111", "principalId": "AIDAJX3TJPA3E2GX6IZYC", "type": "IAMUser", "accessKeyId": "", "userName": "JohnDoe" }, "eventSource": "signin.amazonaws.com", "userAgent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0", "sourceIPAddress": "159.224.244.142", "__conveyor_copy_task_result__": "ok", "MyEventDetails": "Failed to login in account \"Corezoid Dev\" from ip 159.224.244.142", "MfaUsage": "False", "MessageChannel": "sender", "Message": "User: JohnDoe\\nAccount: 111111111111\\nMFA: False\\nType: IAMUser\\n\\nFailed to login in account \"Corezoid Dev\" from ip 159.224.244.142" }

И уведомления в мессенджере Sender.

Итак, наш процесс в Corezoid получает от функции Lambda поток событий и согласно заданной логике отправляет алерты во внешний фронт-енд. В нашем случае, в качестве фронт-енда мы использовали мобильный мессенджер Sender (Sender.mobi), но Corezoid может отправлять через API алерты в любые внешние системы: Slack, E-mail, Sms.

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

Вы можете уже сейчас зарегистрироваться на www.corezoid.com и оценить удобство нашего подхода в обработке событий CloudTrail.

Все материалы из статьи и краткое руководство по их применению доступны в нашем репозитории.