Объем данных, генерируемых во всем мире, растет все более быстрыми темпами. Данные генерируются для поддержки растущего числа вариантов использования, таких как IoT, реклама, игры, мониторинг безопасности, машинное обучение (ML) и многое другое. Рост этих вариантов использования влияет как на объем, так и на скорость потоковой передачи данных и требует от компаний сбора, обработки, преобразования, анализа и загрузки данных в различные хранилища данных почти в реальном времени.
Пожарный шланг данных Amazon Kinesis — это самый простой способ надежно загружать потоковые данные в озера данных, хранилища данных и службы аналитики. По мере роста объема данных, которые вы передаете в Kinesis Data Firehose, вы должны получать ценную информацию и отслеживать состояние приема, преобразования и доставки данных.
В этом посте мы рассмотрим возможности использования метрик потока доставки Firehose и Amazon CloudWatch панели управления, расположенной на консоли Kinesis Data Firehose. Эти возможности позволяют создавать оповещения, когда, например, если назначение, которое вы настроили в Kinesis Data Firehose, имеет недостающие привилегии, неверные настройки или другие проблемы, то Firehose сможет обнаружить это для вас и сообщить о сбое. Другие ошибки, которые также могут возникнуть, связаны с настройкой преобразование данных с использованием Lambda и ваш вызов функции Lambda не удался, или если вы достигли Kinesis Firehose лимиты квот связанные с вашей учетной записью AWS. В этих случаях доставка данных из Kinesis Data Firehose в пункт назначения может задерживаться или завершаться сбоем. Оповещения CloudWatch, описанные в этом посте, должны помочь своевременно выявить такие случаи.
В этом посте также рассматриваются различные упреждающие действия, которые вы можете предпринять при срабатывании сигналов тревоги, например отправка запроса на увеличение квоты или добавление экспоненциальной отсрочки к вашим производителям данных.
Мониторинг потоков доставки и выполнение этих действий гарантирует, что данные доставляются в места назначения без перебоев, что позволяет вашему бизнесу получать ценную информацию почти в реальном времени.
Мониторинг приема данных в Kinesis Data Firehose
Вы можете передавать данные от производителей данных в Kinesis Data Firehose через Потоки данных Amazon Kinesis (как описано далее в этом посте), используя Агент Кинезисили непосредственно с помощью операций API Kinesis Data Firehose. Поставить запись и ПоставитьЗаписьПакет. Когда вы используете Kinesis Data Streams в качестве источника данных, Kinesis Data Firehose автоматически масштабируется по мере масштабирования вашего Kinesis Data Stream. При использовании операций API для прямого приема необходимо проверить лимиты квот связанные с вашей учетной записью AWS, чтобы избежать регулирования запросов API. В зависимости от поведения вашего производителя данных, это регулирование может привести к тому, что ваши производители данных попытаются повторить операцию, что приведет к задержке доставки данных в пункт назначения. Это регулирование также может привести к потере данных, если ваши производители данных не реализуют механизм повторных попыток.
Чтобы получить более глубокое представление об использовании потока доставки Firehose, мы предоставляем дополнительные показатели CloudWatch, которые помогут вам отслеживать и заранее масштабировать лимиты квот: ThrottledRecords, RecordsPerSecondLimit, BytesPerSecondLimitкачества PutRequestsPerSecondLimit. Вы можете использовать панель мониторинга метрик CloudWatch (на мониторинг вкладку на консоли Kinesis Data Firehose), чтобы легко визуализировать текущее использование и ограничения квот.
При приеме данных непосредственно в поток доставки с помощью PutRecord or PutRecordBatch, вы должны следить за Дроссельные записи метрика. Эта метрика представляет собой количество записей, которые были фактически отрегулированы из-за того, что прием данных превысил одно из ограничений потока доставки. Kinesis Data Firehose рассчитывает скорость регулирования во время приема с точностью до 1 секунды, но упомянутые нами показатели приема данных агрегируются и отправляются в CloudWatch каждые 5 минут. Из-за этого вы можете быть ограничены в течение этого 5-минутного окна, даже если показатели приема данных не показывают, что вы достигли предела.
Чтобы получать оповещения до того, как ваши производители данных будут фактически ограничены, вы можете использовать дополнительные показатели CloudWatch чтобы предупредить вас, когда вы собираетесь достичь одного из пределов потока доставки. Этого можно добиться с помощью метрик CloudWatch. IncomingRecords, IncomingBytesкачества IncomingPutRequests. Чтобы проверить пределы этих показателей, см. Квота Amazon Kinesis Data Firehose.
Для создания оповещения CloudWatch можно использовать следующие метрики приема и соответствующие метрики ограничения:
- Рекордсперсекундлимит – Максимальное количество записей, которые могут быть загружены в секунду (
IncomingRecords) - Байтперсекондлимит – Максимальный объем данных, который может быть принят за секунду (
IncomingBytes) - Путрекуестсперсекундлимит – Максимальное количество успешных
PutRecordиPutRecordBatchЗапросы API, которые могут быть выполнены за секунду (IncomingPutRequests)
Чтобы настроить оповещение, которое оповещает вас, когда скорость приема приближается к квоте, вам следует искать процентное соотношение между скоростью приема и соответствующим пределом. Поскольку Kinesis Data Firehose отправляет метрики в CloudWatch каждые 5 минут, вам необходимо разделить метрику на 5-минутный период агрегирования, выраженный в секундах (300). Например, чтобы сгенерировать оповещение, когда скорость входящих записей в секунду превышает 80 % квоты операций API, оповещение CloudWatch должно быть определено следующим образом:
Это дает вам возможность заблаговременно понять, насколько ваши показатели приема близки к ограничениям вашего потока доставки, а также гибкость для изменения процентных уровней в зависимости от вашего варианта использования. Чтобы предотвратить дросселирование узкого места,
вам следует отдельно отслеживать три показателя скорости загрузки потока доставки, которые мы обсуждали.
Определение предупреждений с помощью предупреждений CloudWatch
Вы можете определить тревоги CloudWatch вручную через Консоль управления AWS или с помощью AWS CloudFormation. В этом посте мы рассмотрим оба метода, начиная с шаблона CloudFormation.
Следующий шаблон создает оповещения CloudWatch, которые вы можете просматривать и настраивать в соответствии со своими потребностями.
В процессе создания стека вы указываете имя потока доставки Firehose, который вы хотите отслеживать, и процент квоты, по которой вы хотите получать уведомления при его нарушении, например 80%. После успешного создания стека у вас будут готовы четыре сигнала тревоги CloudWatch.
Чтобы создать оповещения CloudWatch вручную через консоль, выполните следующие действия:
- В консоли Kinesis Data Firehose найдите свой поток доставки.
- На мониторинг выберите значок дополнительных параметров метрики, которую вы хотите отслеживать (в этом примере мы отслеживаем входящие записи в секунду).
- В меню параметров выберите Посмотреть в метриках.
В консоли CloudWatch вы можете увидеть график, отображающий ваши текущие операции API (синяя линия) и ограничение квоты (красная линия).
- Чтобы создать будильник, выберите Математическое выражение.
- Выберите Общий , а затем выбрать Процент.
- В качестве названия метрики введите
Percentage of records per second quota. - Мы используем метрическое выражение
100*(e1/m2), что представляет собой формулу 100*(BytesPerSecond/BytesPerSecondLimit), который был описан ранее и отражает, насколько вы близки к своему максимуму в процентах. - Изменить выражение метрики
e1отMETRICS("m1")/300вm1/300.
Вы также можете изменить метку оси Y.
- На Параметры графика вкладка под Левая ось Y, Для этикетка, войти
Percentage.
- Теперь, когда у вас есть выражение для оповещения, отмените выбор всех остальных выражений и показателей на странице.
Единственным выбранным выражением должно быть то, которое вы только что создали. Теперь вы должны увидеть желаемый процент, как на следующем снимке экрана.
Создание будильника CloudWatch
Теперь вы создали выражение на вашем IncomingRecords и RecordsPerSecond квота, которую вы можете использовать в качестве базы для будильника. При этом вы можете настроить уровень допуска, который требуется вашему бизнес-варианту.
- Выберите значок будильника рядом с вашим выражением лица.
- В Укажите метрику и условия раздел, выберите получение оповещения, когда аварийные сигналы превышают предел 75%.
- В Настройка действий укажите, как перенаправить этот сигнал тревоги.
Вы можете перенаправить этот сигнал тревоги в свои системы мониторинга или на адрес электронной почты через Amazon Простая служба уведомлений (Amazon SNS) тема. Для этого поста мы создаем новую тему SNS и подписываемся admin@example.com к нему.
Действия, которые вы можете предпринять при приближении к пределам
Когда вы приближаетесь к своим пределам, вы можете предпринять несколько различных действий, которые мы опишем в этом разделе.
Запрос увеличения квоты службы
Одно действие, которое вы можете предпринять, увидев предупреждение, — это запросить увеличение квоты с помощью Форма ограничений Amazon Kinesis Data Firehose. Три квоты масштабируются пропорционально, например, если вы увеличиваете квоту пропускной способности для Востока США (Северная Вирджиния), Запада США (Орегон) или Европы (Ирландия) с 5 МБ/с до 10 МБ/с, две другие квоты увеличить с 2,000 запросов в секунду до 4,000 запросов в секунду и с 500,000 1 записей в секунду до XNUMX миллиона записей в секунду. Дополнительные сведения об ограничениях квот сервисов по регионам AWS см. Квота Amazon Kinesis Data Firehose.
Используйте API PutRecordBatch
Если вы используете вызов API PutRecord для доставки событий в поток данных Firehose, и вы достигли квоты запроса/секунды, рассмотрите возможность использования PutRecordBatch Работа API. PutRecordBatch записывает несколько записей данных в поток доставки за один вызов для достижения более высокой пропускной способности на производителя, чем при записи отдельных записей, и уменьшает количество запросов в секунду к потоку доставки.
Реализовать экспоненциальную отсрочку
Как мы упоминали ранее, даже когда вы отслеживаете свой поток доставки, у вас все еще могут быть всплески в вашем потоке данных. Это может быть вызвано внезапными пиками использования вашей системы или внешними событиями, такими как высокая торговая активность на финансовых рынках. Чтобы защитить производителей от нескольких регулируемых записей, вы должны реализовать экспоненциальную отсрочку. Экспоненциальная отсрочка — это широко используемый алгоритм, который можно использовать для уменьшения скорости отправки записей в Kinesis Data Firehose при дросселировании, чтобы производитель мог медленно
ettry для успешной отправки записей.
Ниже приведены ответы API Kinesis Data Firehose при регулировании записей:
- Если вы используете операцию API
PutRecord, возвращенная ошибка службыServiceUnavailableExceptionс кодом состояния HTTP 500. - Если вы используете
PutRecordBatch, вы должны перебратьRequestResponsesмассив и искать отдельные Путрекордбатчреспонентри Код ошибки 500 и Сообщение об ошибкеServiceUnavailableException. Также не забудьте проверить значение Фаиледпуткаунт в ответе, даже если вызов API успешен.
В обоих случаях следует использовать экспоненциальную отсрочку и повторить операцию. Дополнительные сведения о реализации экспоненциальной отсрочки см. Повторные попытки с ошибками и экспоненциальная отсрочка в AWS.
Использование Kinesis Data Streams с Kinesis Data Firehose
Kinesis Data Streams — это масштабируемый и надежный сервис потоковой передачи данных в реальном времени. Ваши производители данных могут создавать данные непосредственно в Kinesis Data Streams, и вы можете настроить Kinesis Data Firehose на использовать данные из Kinesis Data Streams и доставьте его к месту назначения. Когда вы используете Kinesis Data Streams в качестве источника для потока доставки Firehose, упомянутые выше ограничения пропускной способности не применяются. Вам не нужно беспокоиться об ограничениях пропускной способности, поскольку Kinesis Data Firehose автоматически масштабируется в соответствии с количеством сегментов, которые есть в вашем потоке данных Kinesis.
Если вы присоединяете поток доставки Firehose в качестве потребителя к потоку данных Kinesis и у вас есть несколько приложений-потребителей, которые считывают данные из потока данных Kinesis, например AWS Lambda (См. Использование AWS Lambda с Amazon Kinesis), убедитесь, что все потребительские приложения не нарушают общая скорость чтения шарда 2 МБ. Это может привести к тому, что поток данных Kinesis будет ограничивать пропускную способность чтения ваших потребительских приложений, включая Kinesis Data Firehose.
Если требуется больше емкости чтения, некоторые потребители приложений, такие как Lambda (см. AWS Lambda поддерживает Kinesis Data Streams Enhanced Fan-Out и HTTP/2 для более быстрой потоковой передачи.) или пользовательские потребители, которые были разработаны с помощью Пользовательская библиотека Kinesis может поддерживать выделенную пропускную способность от Kinesis Data Streams с использованием расширенное разветвление, который в настоящее время не поддерживается Kinesis Data Firehose. Эта функция обеспечивает изолированное подключение этих потребительских приложений к потоку с исходящей пропускной способностью 2 МБ/с, поэтому они не влияют на другие потребительские приложения, считывающие данные из сегментов.
Если вам нужно больше емкости для приема, вы можете легко увеличить количество сегментов в потоке с помощью консоли или API UpdateShardCount.
Мониторинг доставки данных Kinesis Data Firehose
В случае тайм-аутов сети, отсутствия прав или неправильных настроек потока доставки, таких как неправильный конфигурация назначения or Служба управления ключами AWS (АМС КМС) ключ АРН, доставка ваших данных из Kinesis Data Firehose в место назначения может быть задержана или не удалась. Ошибки также могут возникать, если вы настроили преобразование данных с использованием Lambda и ваш вызов функции Lambda не удался.
Когда Kinesis Data Firehose обнаруживает ошибки доставки или обработки, он повторяет попытку до тех пор, пока настроенный продолжительность повтора истекает. Если продолжительность повторных попыток истекает, а данные не были успешно доставлены, Kinesis Data Firehose сохраняет данные внутри до максимального периода 24 часов. Если проблема не устранена по истечении максимального 24-часового периода хранения, Kinesis Data Firehose удаляет данные, что приводит к их потере.
Когда такие проблемы с доставкой данных сохраняются, актуальность данных метрика, то есть возраст самой старой записи в Kinesis Data Firehose, которая еще не была доставлена, постоянно увеличивается. Чтобы получать оповещения в таких случаях, вы должны создать оповещение CloudWatch, когда метрика свежести данных превышает пороговое значение в 4 часа. Мы также рекомендуем установить сигнал тревоги для наблюдения за историческим p90 значения метрики свежести данных. Например, установите определенный уровень допуска (например, на 50 % выше наблюдаемого значения) в качестве порога срабатывания сигнализации для обнаружения изменений актуальности данных.
Вам следует отслеживать показатель актуальности данных, который имеет отношение к месту назначения Kinesis Data Firehose, например DeliveryToS3.DataFreshness, DeliveryToAmazonOpenSearchService.DataFreshness, DeliveryToSplunk.DataFreshnessили DeliveryToHttpEndpoint.DataFreshness, Для получения дополнительной информации см. Мониторинг Kinesis Data Firehose с помощью CloudWatch Metrics.
Если срабатывает этот сигнал тревоги, вы должны принять меры, чтобы понять основную причину изменения актуальности данных. Причиной такой вариации может быть изменение вашего Логика лямбда-преобразования или изменение конфигурации Лямбда-параллелизм При использовании Преобразование данных Kinesis Data Firehose. Это также может быть результатом изменения параметров конфигурации, схема преобразования форматаили добавленный тип записи. Для получения дополнительной информации см. Показатель свежести данных увеличивается или не передается или вы можете оставить заявку в техподдержку если нужно.
Если доставка данных не удалась из-за преобразования данных или проблемы в месте назначения, в некоторых случаях вы можете найти подробные журналы сбоев в журналах CloudWatch, которые могут помочь вам устранить проблему.
Мы также рекомендуем отслеживать скорость передачи данных в байтах к месту назначения (например, DeliveryToS3.Byte), который должен соответствовать скорости приема данных или превышать ее (IncomingBytes) на устойчивой средней основе, чтобы избежать увеличения актуальность данных метрика и возможная возможная потеря данных. Если наблюдаемые скорости доставки данных ниже, чем скорости приема, рассмотрите возможность настройки узких мест, таких как уровни параллелизма Lambda или Логика лямбда-преобразования при использовании с преобразованием данных Kinesis Data Firehose.
Чтобы получить дополнительные сведения о доставке ваших данных к месту назначения, мы предоставляем метрики CloudWatch, которые вы можете отслеживать. Например, вы можете отслеживать количество доставленных записей, чтобы отслеживать данные, поступающие в места назначения из Kinesis Data Firehose. Для получения дополнительной информации и дополнительных показателей для каждого пункта назначения см. Мониторинг Kinesis Data Firehose с помощью CloudWatch Metrics.
Заключение
В этом посте мы обсудили возможности использования метрик потока доставки Firehose и панели управления CloudWatch, расположенной на вашей консоли Kinesis Data Firehose. Это позволяет вам получать оперативную информацию о приеме и доставке данных вашего потока доставки Firehose, а также создавать оповещения CloudWatch, которые будут уведомлены при нарушении одного из ваших пороговых значений. Мы также рассмотрели различные действия, которые вы можете предпринять при срабатывании этих сигналов тревоги, такие как отправка запроса на увеличение вашей квоты или добавление экспоненциальной отсрочки к вашим производителям данных.
Контролируйте свои потоки доставки и выполняйте эти действия, чтобы убедиться, что ваши бизнес-данные доставляются в места назначения без перебоев, что позволяет вашему бизнесу получать ценную информацию почти в реальном времени.
Об авторе
Алон Гендлер является менеджером по архитектуре стартап-решений в Amazon Web Services. Он работает с клиентами AWS, помогая им решать сложные проблемы и создавать безопасные, отказоустойчивые, масштабируемые и высокопроизводительные приложения в облаке. Алон увлечен данными и помогает клиентам получить от них максимальную отдачу.
