Блог 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) |
Используется для запуска/закрытия эскалации по количеству задач в узле. Например, пусть необходимо реагировать на разное количество задач в очереди, которые требуют обработки. Если количество объектов в очереди превышает:
При снижении количества объектов в очереди мы сможем уведомить менеджера/руководителя о уменьшении количества необработанных задач |
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.
Все материалы из статьи и краткое руководство по их применению доступны в нашем репозитории.