Поделиться через


Источники событий Azure Time Series Insights второго поколения

Заметка

Служба "Аналитика временных рядов" будет прекращена 7 июля 2024 года. Рассмотрите возможность переноса существующих сред в альтернативные решения как можно скорее. Дополнительные сведения об устаревании и миграции см. в нашей документации .

Среда Аналитики временных рядов Azure 2-го поколения может иметь до двух источников событий потоковой передачи. В качестве входных данных поддерживаются два типа ресурсов Azure:

События должны отправляться в формате JSON с кодировкой UTF-8.

Создание или изменение источников событий

Источник событий — это связь между узлом и средой Azure Time Series Insights 2-го поколения, а в группе ресурсов создается отдельный ресурс типа Time Series Insights event source. Ресурсы Центра Интернета вещей или Центра событий могут находиться в той же подписке Azure, что и среда Azure Time Series Insights 2-го поколения, или в другой подписке. Однако рекомендуется разместить среду Аналитики временных рядов Azure и Центр Интернета вещей или Концентратор событий в одном регионе Azure.

Вы можете использоватьпортала Azure , Azure CLI, шаблонов Azure Resource Managerи REST API для создания, изменения или удаления источников событий среды.

Предупреждение

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

Параметры запуска

При создании источника событий можно указать, какие предварительно существующие данные следует собирать. Этот параметр является необязательным. Доступны следующие параметры:

Имя Описание Пример шаблона Azure Resource Manager
Первая доступная Загрузка всех существующих данных, хранящихся в IoT Центре или Центре событий "ingressStartAt": {"type": "EarliestAvailable"}
ВремяСозданияИсточникаСобытия Начните прием данных, поступающих после создания источника событий. Все существующие данные, которые передавались в потоке до создания источника событий, будут игнорироваться. Это параметр по умолчанию на портале Azure "ingressStartAt": {"type": "EventSourceCreationTime"}
CustomEnqueuedTime Ваша среда будет принимать данные начиная с заданного пользовательского времени (UTC) и далее. Все события, которые были поставлены в очередь в вашем Центре интернета вещей или концентраторе событий в момент или после вашего заданного времени постановки в очередь, будут приняты и сохранены. Все события, которые были доставлены до вашего времени добавления в очередь, будут игнорироваться. Обратите внимание, что "время постановки в очередь" относится ко времени (в формате UTC), когда событие прибыло в ваш Центр Интернета вещей или Концентратор событий. Это отличается от пользовательского свойства метки времени , которое находится в тексте события. "ingressStartAt": {"type": "CustomEnqueuedTime", "time": "2021-03-01T17:00:00.20Z"}

Важный

  • Если вы выберете EarliestAvailable и имеете много существующих данных, возможно, вы столкнетесь с высокой начальной задержкой, так как среда Azure Time Series Insights Gen2 обрабатывает все ваши данные.
  • Эта высокая задержка в конечном итоге должна утихнуть по мере индексации данных. Отправьте запрос в службу поддержки на портале Azure, если вы испытываете постоянную высокую задержку.
  • Самое раннее доступное

диаграмма с самой ранней доступностью

  • ВремяСозданияИсточникСобытия

диаграмма EventSourceCreationTime

  • CustomEnqueuedTime

Диаграмма CustomEnqueuedTime

Рекомендации по приему потоковой передачи

  • Всегда создайте уникальную группу потребителей для среды Аналитики временных рядов Azure 2-го поколения, чтобы использовать данные из источника событий. Повторное использование групп потребителей может привести к случайным отключениям, которые могут вызвать потерю данных.

  • Настройте среду Аналитики временных рядов Azure 2-го поколения и Центр Интернета вещей и (или) Центры событий в одном регионе Azure. Хотя можно настроить источник событий в отдельном регионе, этот сценарий не поддерживается, и мы не можем гарантировать высокий уровень доступности.

  • Не превышайте ограничения пропускной способности среды или лимита на раздел.

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

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

  • Узнайте, как будут экранированы свойства и как данные JSON будут уплощены и сохранены.

  • Следуйте принципу наименьших привилегий при предоставлении строк подключения источника событий. Для центров событий настройте политику общего доступа с только правом на отправку , а для Центра Интернета вещей настройте только разрешение подключения службы .

Осторожность

Если удалить Центр Интернета вещей или Концентратор событий и повторно создать ресурс с тем же именем, необходимо создать новый источник событий и подключить новый Центр Интернета вещей или Концентратор событий. Обработка данных не начнётся, пока вы не завершите этот шаг.

Производственные нагрузки

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

  • Увеличьте время хранения данных Центра Интернета вещей или Центра событий до максимального количества семи дней.

  • Создание оповещений среды на портале Azure. Оповещения на основе метрик платформы позволяют проверять поведение сквозного конвейера. Здесь вы найдете инструкции по созданию оповещений и управлению ими . Предлагаемые условия генерации оповещений:

    • IngressReceivedMessagesTimeLag больше 5 минут
    • IngressReceivedBytes равно 0
  • Сохраняйте балансировку нагрузки приема между разделами Центра Интернета вещей или Концентратора событий.

Прием исторических данных

Использование конвейера потоковой передачи для импорта исторических данных в настоящее время не поддерживается в Аналитике временных рядов Azure 2-го поколения. Если вам нужно импортировать прошлые данные в среду, следуйте приведенным ниже рекомендациям.

  • Не выполняйте потоковую передачу динамических и исторических данных параллельно. Обработка данных вне заданного порядка приведет к снижению производительности запросов.
  • Для достижения лучшей производительности загружайте исторические данные в хронологическом порядке.
  • Соблюдайте ограничения на пропускную способность ввода данных, указанные ниже.
  • Отключите "Теплое хранилище", если данные старше периода его хранения.

Метка времени источника события

При настройке источника событий вам будет предложено указать свойство идентификатора метки времени. Свойство метки времени используется для отслеживания событий с течением времени. Это время, которое будет использоваться в качестве метки времени $ts в API запросов и для построения рядов в обозревателе аналитики временных рядов Azure. Если свойство не предоставляется во время создания, или если в событии отсутствует свойство метки времени, будет использоваться время добавления события в IoT Hub или Event Hubs в качестве значения по умолчанию. Значения свойств метки времени хранятся в формате UTC.

Как правило, пользователи предпочитают настроить свойство метки времени и использовать время, когда датчик или тег создали данные, а не время, когда данные были поставлены в очередь хабом по умолчанию. Это особенно необходимо, если устройства имеют периодические потери подключения, и пакет отложенных сообщений отправляется в Azure Time Series Insights Gen2.

Если ваша пользовательская метка времени находится во вложенном объекте JSON или массиве, необходимо указать правильное имя свойства согласно нашим соглашениям об именовании для выравнивания и экранирования . Например, метка времени источника события для полезных данных JSON, показанная здесь,, должна быть записана как "values.time".

Смещения часового пояса

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

Смещение часового пояса должно быть отформатировано как одно из следующих:

±HHMMZ
±HH:MM
±HH:MMZ

Дальнейшие действия

  • Прочтите правила неструктурирования и экранирования JSON и, чтобы понять, как будут храниться события.

  • Общие сведения об ограничениях пропускной способности среды