Сбор и транспортировка метрик

Область применения:IoT Edge 1.4 checkmark IoT Edge 1.4

Важно!

IoT Edge 1.4 является поддерживаемым выпуском. Если вы используете более ранний выпуск, см. статью Обновление IoT Edge.

Вы можете удаленно отслеживать парк устройств IoT Edge с помощью Azure Monitor и интеграции со встроенными метриками. Чтобы включить эту возможность на своем устройстве, добавьте в развертывание модуль metrics-collector и настройте его для получения и передачи метрик модуля для Azure Monitor.

Чтобы настроить мониторинг на устройстве IoT Edge, выполните инструкции по мониторингу устройств IoT Edge. Вы узнаете, как добавить модуль сборщика метрик на устройство. В этой статье представлен обзор архитектуры мониторинга и описаны варианты настройки метрик на устройстве.

Интеграция IoT Edge с Azure Monitor(4:06)

Архитектура

Screenshot of the metrics monitoring architecture with IoT Hub.

Примечание. Description
1 Все модули должны генерировать метрики на основе модели данных Prometheus. Хотя встроенные метрики по умолчанию позволяют достаточно полно контролировать рабочую нагрузку, для создания характерных для сценария метрик для улучшения решения мониторинга также можно использовать настраиваемые модули. Сведения об инструментировании настраиваемых модулей с помощью библиотек с открытым исходным кодом приведены в статье Добавление настраиваемых метрик.
2️ Модуль сборщика метрик metrics-collector — это модуль IoT Edge от Майкрософт, который собирает метрики модуля рабочей нагрузки и передает их за пределы устройства. Для получения (сбора) метрик используется модель извлечения (запроса). Частоту сбора, конечные точки и фильтры можно настроить для управления исходящими из модуля данными. Дополнительные сведения см. в разделе о параметрах конфигурации сборщика метрик далее в этой статье.
3️ Отправлять метрики из модуля metrics-collector в облако можно двумя способами. В первом случае метрики отправляются в Log Analytics1. Собранные метрики принимаются в указанную рабочую область Log Analytics с использованием определенной встроенной таблицы под названием InsightsMetrics. Схема этой таблицы совместима с моделью данных метрик Prometheus.

Для этого варианта требуется доступ к рабочей области на исходящем порту 443. В конфигурации модуля должны быть указаны идентификатор и ключ рабочей области Log Analytics. Сведения об использовании этой возможности в сетях с ограничениями см. в разделе о сценариях с ограниченным сетевым доступом далее в этой статье.
4️ Каждая запись метрики содержит идентификатор ResourceId, который был указан в конфигурации модуля. Это автоматически связывает метрику с указанным ресурсом (например, Центром Интернета вещей). В результате курированные шаблоны книг IoT Edge могут получать метрики с помощью запросов к ресурсу.

Такой подход также позволяет нескольким центрам IoT безопасно использовать совместно одну рабочую область Log Analytics в качестве базы данных метрик.
5️ Во втором случае метрики отправляются в Центр Интернета вещей1. Модуль сборщика можно настроить для отправки полученных метрик в виде сообщений JSON в кодировке UTF-8 с устройства в облако через модуль edgeHub. При этом становится возможным мониторинг заблокированных устройств IoT Edge, которым разрешен внешний доступ только к конечной точке Центра Интернета вещей. Также можно отслеживать дочерние устройства IoT Edge во вложенной конфигурации, где дочерние устройства могут обращаться только к своим родительским объектам.
6️ Если метрики проходят через центр Интернета вещей, необходимо настроить (однократный) облачный рабочий процесс. Рабочий процесс обрабатывает сообщения, поступающие из модуля сборщика метрик, и отправляет их в рабочую область Log Analytics. Рабочий процесс позволяет использовать функции курированных визуализаций и оповещений даже для метрик, поступающих через этот альтернативный маршрут. Дополнительные сведения о настройке этого облачного рабочего процесса см. в разделе о маршрутизации метрик через Центр Интернета вещей.

1 В настоящее время прямая передача метрик в Log Analytics с устройства IoT Edge с помощью первого способа — более простой путь, требующий минимальной настройки. Первый способ предпочтителен, если только в вашем конкретном сценарии не требуется второй вариант, в котором устройство IoT Edge взаимодействует только с центром Интернета вещей.

Модуль сборщика метрик

Вы можете добавить в развертывание IoT Edge модуль сборщика метрик от Майкрософт для сбора метрик модуля и их отправки в Azure Monitor. Это модуль с открытым исходным кодом, и он доступен в репозитории GitHub IoT Edge.

Модуль metrics-collector предоставляется в виде многоархитектурного образа контейнера Docker, который поддерживает Linux x64, ARM32, ARM64 и Windows X64 (версия 1809). Он опубликован по адресу mcr.microsoft.com/azureiotedge-metrics-collector.

Он также доступен в каталоге модулей IoT Edge.

Настройка сборщика данных

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

Environment variable name Description
ResourceId Идентификатор ресурса центра Интернета вещей, с которым взаимодействует устройство. Дополнительные сведения см. в разделе об идентификаторе ресурса.

Обязательный

Значение по умолчанию: нет
UploadTarget Определяет, отправляются ли метрики непосредственно в Azure Monitor по протоколу HTTPS или в центр Интернета вещей как сообщения D2C. Дополнительные сведения см. в разделе о целевом объекте отправки.

Возможные значения — AzureMonitor или IoTMessage.

Не требуется

Значение по умолчанию: AzureMonitor
LogAnalyticsWorkspaceId Идентификатор рабочей области Log Analytics.

Обязателен только в том случае, если UploadTarget имеет значение AzureMonitor.

Значение по умолчанию: нет
LogAnalyticsSharedKey Ключ рабочей области Log Analytics.

Обязателен только в том случае, если UploadTarget имеет значение AzureMonitor.

Значение по умолчанию: нет
ScrapeFrequencyInSecs Интервал времени в секундах, с которым собираются и передаются метрики.

Пример: 600.

Не требуется

Значение по умолчанию: 300
MetricsEndpointsCSV Список через запятую конечных точек, с которых собираются метрики Prometheus. В этом списке должны быть все конечные точки модуля для сбора метрик.

Пример: http://edgeAgent:9600/metrics, http://edgeHub:9600/metrics, http://MetricsSpewer:9417/metrics

Не требуется

Значение по умолчанию: http://edgeHub:9600/metrics, http://edgeAgent:9600/metrics
AllowedMetrics Список собираемых метрик игнорируется. Для отключения сбора задайте пустую строку. Дополнительные сведения см. в разделе о списках разрешений и запретов.

Пример: metricToScrape{quantile=0.99}[endpoint=http://MetricsSpewer:9417/metrics]

Не требуется

Значение по умолчанию: пустой
BlockedMetrics Список метрик, которые нужно игнорировать. Переопределяет разрешенные метрики, поэтому метрика не сообщается, если она включена в оба списка. Дополнительные сведения см. в разделе о списках разрешений и запретов.

Пример: metricToIgnore{quantile=0.5}[endpoint=http://VeryNoisyModule:9001/metrics], docker_container_disk_write_bytes

Не требуется

Значение по умолчанию: пустой
CompressForUpload Определяет, следует ли использовать сжатие при отправке метрик. Применяется ко всем целевым объектам передачи.

Пример: true

Не требуется

Значение по умолчанию: true
AzureDomain Задает домен Azure верхнего уровня, который будет использоваться при приеме метрик непосредственно в Log Analytics.

Пример: azure.us

Не требуется

Значение по умолчанию: azure.com

ИД ресурса

Для модуля metrics-collector требуется идентификатор Azure Resource Manager центра Интернета вещей, к которому относится устройство IoT Edge. Этот идентификатор задается в качестве значения переменной среды ResourceID.

Идентификатор ресурса имеет следующий формат:

/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Devices/IoTHubs/<iot hub name>

ИД ресурса можно найти на портале Azure на странице свойств центра Интернета вещей.

Screenshot the shows how to retrieve your resource ID from the IoT Hub properties.

Идентификатор также можно получить с помощью команды az resource show:

az resource show -g <resource group> -n <hub name> --resource-type "Microsoft.Devices/IoTHubs"

Целевой объект Upload

Параметр конфигурации UploadTarget определяет, отправляются ли метрики непосредственно в Azure Monitor или в центр Интернета вещей.

Если задать для UploadTarget значение IoTMessage, ваши метрики модуля публикуются как сообщения IoT. Эти сообщения создаются в виде объектов JSON в кодировке UTF8 от конечной точки /messages/modules/<metrics collector module name>/outputs/metricOutput. Например, если модуль сборщика метрик IoT Edge называется IoTEdgeMetricsCollector, то конечная точка ./messages/modules/IoTEdgeMetricsCollector/outputs/metricOutput Используется следующий формат:

[{
    "TimeGeneratedUtc": "<time generated>",
    "Name": "<prometheus metric name>",
    "Value": <decimal value>,
    "Label": {
        "<label name>": "<label value>"
    }
}, {
    "TimeGeneratedUtc": "2020-07-28T20:00:43.2770247Z",
    "Name": "docker_container_disk_write_bytes",
    "Value": 0.0,
    "Label": {
        "name": "AzureMonitorForIotEdgeModule"
    }
}]

Списки разрешений и запретов

Параметры конфигурации AllowedMetrics и BlockedMetrics принимают разделенные запятыми списки селекторов метрик. Метрика соответствует списку и включается или исключается, если она соответствует одной или нескольким метрикам в любом списке.

Для селекторов метрик используется формат, аналогичный подмножеству языка запросов PromQL.

metricToSelect{quantile=0.5,otherLabel=~Re[ge]*|x}[http://VeryNoisyModule:9001/metrics]

Селекторы метрик состоят из трех элементов:

Имя метрики (metricToSelect).

  • В именах метрик можно использовать подстановочные знаки * (любой символ) и ? (любой отдельный символ). Например, *CPU соответствует значениям maxCPU и minCPU, но не CPUMaximum. ???CPU соответствует значениям maxCPU и minCPU, но не maximumCPU.
  • Этот компонент является обязательным в селекторе метрик.

Селекторы на основе меток ({quantile=0.5,otherLabel=~Re[ge]*|x}).

  • В фигурные скобки можно заключить несколько значений метрики. Значения должны быть разделены запятыми.
  • Метрика сопоставляется, если по крайней мере все метки в селекторе присутствуют, а также совпадают.
  • Как и в PromQL, допускаются указанные ниже операторы сопоставления.
    • =: совпадение для меток, точно соответствующих указанной строке (с учетом регистра).
    • !=: совпадение для меток, неточно соответствующих указанной строке.
    • =~: совпадение для меток, соответствующих указанному регулярному выражению. Пример: label=~CPU|Mem|[0-9]*
    • !~: совпадение для меток, не соответствующих указанному регулярному выражению.
    • Regex полностью привязан (A ^ и $ автоматически добавляются в начало и конец каждого регулярного выражения)
    • Этот компонент является необязательным в селекторе метрик.

Селектор конечных точек ([http://VeryNoisyModule:9001/metrics]).

  • URL-адрес должен точно соответствовать URL-адресу, указанному в параметре MetricsEndpointsCSV.
  • Этот компонент является необязательным в селекторе метрик.

Метрика должна соответствовать всем элементам этого селектора. Он должен соответствовать имени и иметь все те же метки с соответствующими значениями и поступать из данной конечной точки. Например, не mem{quantile=0.5,otherLabel=foobar}[http://VeryNoisyModule:9001/metrics] соответствует селектору mem{quantile=0.5,otherLabel=~foo|bar}[http://VeryNoisyModule:9001/metrics]. Для реализации алгоритма с объединением через "или" вместо "и" следует использовать несколько селекторов.

Например, чтобы разрешить пользовательскую метрику с любой меткой из модуляmodule1, но разрешить только ту же метку mem с module2 меткойagg=p99, можно добавить AllowedMetricsследующий селектор:

mem{}[http://module1:9001/metrics] mem{agg="p99"}[http://module2:9001/metrics]

Кроме того, чтобы разрешить пользовательские метрики и cpu для любых меток mem или конечной точки, добавьте следующееAllowedMetrics:

mem cpu

Сценарии с ограниченным сетевым доступом

Если вы отправляете метрики непосредственно в рабочую область Log Analytics, разрешите исходящий доступ к следующим URL-адресам:

  • https://<LOG_ANALYTICS_WORKSPACE_ID>.ods.opinsights.azure.com/*
  • https://<LOG_ANALYTICS_WORKSPACE_ID>.oms.opinsights.azure.com/*

Соображения, связанные с использованием прокси-сервера

Модуль metrics-collector написан на .NET Core. Поэтому для обмена данными через прокси-сервер для него действуют те же рекомендации, что и для системных модулей.

Для сбора метрик из локальных модулей используется протокол HTTP. Чтобы запретить локальные маршруты через прокси-сервер, задайте переменную среды NO_PROXY.

Задайте в качестве значения NO_PROXY список через запятую имен узлов, которые следует исключить. Используйте в качестве имен узлов имена модулей. Например: edgeHub,edgeAgent,myCustomModule.

Перенаправление метрик

Иногда необходимо принять метрики через Центр Интернета вещей вместо отправки их непосредственно в Log Analytics. Пример — мониторинг устройств IoT Edge во вложенной конфигурации, когда у дочерних устройств есть доступ только к центру IoT Edge родительского устройства. Еще одним примером является развертывание устройства IoT Edge с исходящим сетевым доступом только к Центр Интернета вещей.

Чтобы реализовать мониторинг в этом сценарии, модуль metrics-collector можно настроить для отправки метрик в виде сообщений с устройства в облако (D2C) через модуль edgeHub. Эту возможность можно включить, задав для переменной среды UploadTarget значение IoTMessage в конфигурации сборщика.

Совет

Не забудьте добавить маршрут edgeHub для доставки сообщений метрик из модуля сборщика в центр Интернета вещей. Оно выглядит следующим образом: FROM /messages/modules/replace-with-collector-module-name/* INTO $upstream.

Этот параметр требует дополнительной настройки, облачного рабочего процесса для доставки сообщений метрик, поступающих в Центр Интернета вещей в рабочую область Log Analytics. Без настройки другие части интеграции, такие как курированные визуализации и оповещения , не работают.

Примечание.

При использовании этого варианта затраты будут выше. Сообщения метрик будут учитываться в квоте сообщений центра Интернета вещей. Кроме того, будет начисляться плата за прием в Log Analytics и ресурсы облачных рабочих процессов.

Пример облачного рабочего процесса

Облачный рабочий процесс, который доставляет сообщения метрик из центра Интернета вещей в Log Analytics, доступен в составе примера ведения журнала и мониторинга для IoT Edge. Этот пример можно развернуть в существующих облачных ресурсах или использовать в качестве основы для рабочего развертывания.

Следующие шаги

Ознакомьтесь с различными типами курированных визуализаций, которые реализуются через Azure Monitor.