Конвейер Azure Monitor — это конвейер приема данных, обеспечивающий согласованную и централизованную сбор данных для Azure Monitor. Конвейер на границе включает масштабируемую коллекцию и маршрутизацию данных телеметрии перед отправкой в облако. Он может кэшировать данные локально и синхронизироваться с облаком при восстановлении подключения и маршрутизации телеметрии в Azure Monitor в случаях, когда сеть сегментирована и данные не могут отправляться непосредственно в облако. В этой статье описывается, как включить и настроить конвейер в пограничной среде.
Обзор
Конвейер Azure Monitor на пограничном уровне — это контейнерное решение, развернутое в кластере Kubernetes с поддержкой Arc и использующее сборщик OpenTelemetry в качестве основы. На следующей схеме показаны компоненты конвейера на границе. Один или несколько потоков данных прослушивают входящие данные от клиентов, а расширение конвейера пересылает данные в облако, используя локальный кэш при необходимости.
Файл конфигурации конвейера определяет потоки данных и свойства кэша для конвейера на границе. DCR определяет схему данных, отправляемых в облачный конвейер, преобразование для фильтрации или изменения данных и назначения, в котором должны отправляться данные. Каждое определение потока данных для конфигурации конвейера указывает DCR и поток в этом DCR, который будет обрабатывать эти данные в облачном конвейере.
Примечание.
Приватный канал поддерживается пограничным конвейером для подключения к облачному конвейеру.
Для включения конвейера Azure Monitor на границе требуются следующие компоненты и конфигурации. Если вы используете портал Azure для настройки конвейера на границе, то для вас создается каждый из этих компонентов. С другими методами необходимо настроить каждую из них.
Компонент
Description
Расширение контроллера пограничного конвейера
Расширение, добавленное в кластер Kubernetes с поддержкой Arc, для поддержки функций конвейера — microsoft.monitor.pipelinecontroller.
Экземпляр контроллера пограничного конвейера
Экземпляр пограничного конвейера, работающего в кластере Kubernetes с поддержкой Arc.
Поток данных
Сочетание получателей и экспортеров, работающих на экземпляре контроллера конвейера. Получатели принимают данные от клиентов и экспортеров для доставки данных в Azure Monitor.
Конфигурация конвейера
Файл конфигурации, определяющий потоки данных для экземпляра конвейера. Каждый поток данных включает приемника и экспортера. Получатель прослушивает входящие данные, а экспортер отправляет данные в место назначения.
Конечная точка сбора данных (DCE)
Конечная точка, в которой данные отправляются в конвейер Azure Monitor. Конфигурация конвейера содержит свойство для URL-адреса DCE, чтобы экземпляр конвейера знал, куда отправлять данные.
Настройка
Description
Правило сбора данных (DCR)
Файл конфигурации, определяющий способ получения данных в облачном конвейере и место его отправки. DCR также может включать преобразование для фильтрации или изменения данных перед отправкой в место назначения.
Конфигурация конвейера
Конфигурация, определяющая потоки данных для экземпляра конвейера, включая потоки данных и кэш.
Поддерживаемые конфигурации
Поддерживаемые дистрибутивы
Конвейер Azure Monitor на периферии поддерживается в следующих дистрибутивах Kubernetes:
Canonical
Поставщик API кластеров для Azure
K3
Rancher Kubernetes Engine
VMware Tanzu Kubernetes Grid
Поддерживаемые расположения
Конвейер Azure Monitor на пограничном сервере поддерживается в следующих регионах Azure:
Рабочая область Log Analytics в Azure Monitor для получения данных из конвейера на границе. Дополнительные сведения о создании рабочей области Log Analytics см. в портал Azure.
Следующие поставщики ресурсов должны быть зарегистрированы в подписке Azure. Ознакомьтесь с разделом Поставщики и типы ресурсов Azure.
Microsoft.Insights
Microsoft.Monitor
Рабочий процесс
Вам не требуется подробное представление о различных шагах, выполняемых конвейером Azure Monitor, чтобы настроить его с помощью портал Azure. Возможно, вам потребуется более подробное представление об этом, если вы используете другой метод установки или если необходимо выполнить более расширенную конфигурацию, например преобразование данных, прежде чем он хранится в его назначении.
В следующих таблицах и схемах описаны подробные шаги и компоненты процесса сбора данных с помощью конвейера на границе и передачи его в облачный конвейер для хранения в Azure Monitor. Кроме того, в таблицах используется конфигурация, необходимая для каждого из этих компонентов.
Этап
Действие
Поддержка конфигурации
1.
Клиент отправляет данные в приемник пограничных конвейеров.
Клиент настраивается с IP-адресом и портом приемника пограничных конвейеров и отправляет данные в ожидаемом формате для типа приемника.
2.
Получатель перенаправит данные экспортеру.
Получатель и экспортер настроены в одном конвейере.
3.
Экспортер пытается отправить данные в облачный конвейер.
Экспортер в конфигурации конвейера содержит URL-адрес DCE, уникальный идентификатор DCR и поток в DCR, определяющий способ обработки данных.
3а.
Экспортер сохраняет данные в локальном кэше, если он не может подключиться к DCE.
Постоянный том для кэша и конфигурации локального кэша включен в конфигурации конвейера.
Этап
Действие
Поддержка конфигурации
4.
Облачный конвейер принимает входящие данные.
DCR содержит определение схемы для входящего потока, которое должно соответствовать схеме данных, поступающих из конвейера на краю.
5.
Облачный конвейер применяет преобразование к данным.
DCR включает преобразование, которое фильтрует или изменяет данные перед отправкой в место назначения. Преобразование может фильтровать данные, удалять или добавлять столбцы или полностью изменять ее схему. Выходные данные преобразования должны соответствовать схеме целевой таблицы.
6.
Облачный конвейер отправляет данные в место назначения.
DCR включает назначение, указывающее рабочую область Log Analytics и таблицу, в которой будут храниться данные.
Сегментированная сеть
Сегментация сети — это модель, в которой используются программные периметры для создания другой системы безопасности для разных частей сети. В этой модели может быть сегмент сети, который не может подключаться к Интернету или к другим сегментам сети. Конвейер на пограничном уровне можно использовать для сбора данных из этих сетевых сегментов и отправки его в облачный конвейер.
Перед настройкой процесса сбора данных для конвейера на границе необходимо создать таблицу в рабочей области Log Analytics для получения данных. Это должна быть настраиваемая таблица, так как встроенные таблицы в настоящее время не поддерживаются. Схема таблицы должна соответствовать получаемым данным, но в процессе сбора существует несколько шагов, в которых можно изменить входящие данные, поэтому схема таблицы не должна совпадать с исходными данными, которые вы собираете. Единственным требованием для таблицы в рабочей области Log Analytics является наличие столбца TimeGenerated .
Дополнительные сведения о различных методах создания таблицы см. в журналах Azure Monitor и их удалении. Например, используйте приведенную ниже команду CLI, чтобы создать таблицу с тремя столбцами, называемыми Body, TimeGeneratedи SeverityText.
Пограничные устройства в некоторых средах могут возникать периодически из-за различных факторов, таких как перегрузка сети, помехи сигналов, отключение питания или мобильность. В этих средах конвейер можно настроить на пограничном уровне для кэширования данных, создав постоянный том в кластере. Процесс для этого зависит от конкретной среды, но конфигурация должна соответствовать следующим требованиям:
Пространство имен метаданных должно совпадать с указанным экземпляром конвейера Azure Monitor.
Режим доступа должен поддерживаться ReadWriteMany.
После создания тома в соответствующем пространстве имен настройте его с помощью параметров в файле конфигурации конвейера ниже.
Внимание
Каждая реплика пограничного конвейера хранит данные в расположении в постоянном томе, относящееся к этой реплике. Уменьшение количества реплик при отключении кластера от облака приведет к тому, что при восстановлении подключения данные не будут заполнены.
Данные извлекаются из кэша с помощью первого выхода (FIFO). Все данные старше 48 часов будут удалены.
Включение и настройка конвейера
Текущие параметры включения и настройки подробно описаны на вкладках ниже.
При использовании портал Azure для включения и настройки конвейера создаются все необходимые компоненты на основе выбранных элементов. Это экономит вас от сложности создания каждого компонента по отдельности, но вам потребуется использовать другие методы.
Выполните одно из следующих действий в портал Azure, чтобы запустить процесс установки для конвейера Azure Monitor:
В меню конвейеров Azure Monitor (предварительная версия) нажмите кнопку "Создать".
В меню для кластера Kubernetes с поддержкой Arc выберите расширения и добавьте расширение конвейера Azure Monitor (предварительная версия).
На вкладке "Базовый " появится следующая информация, чтобы развернуть экземпляр расширения и конвейера в кластере.
Параметры на этой вкладке описаны в следующей таблице.
Свойство
Description
Имя экземпляра
Имя экземпляра конвейера Azure Monitor. Должен быть уникальным для подписки.
Отток подписок
Подписка Azure для создания экземпляра конвейера.
Группа ресурсов
Группа ресурсов для создания экземпляра конвейера.
Имя кластера
Выберите кластер Kubernetes с поддержкой Arc, на котором будет установлен конвейер.
Пользовательское расположение
Пользовательское расположение для кластера Kubernetes с поддержкой Arc. Это будет автоматически заполнено именем настраиваемого расположения, которое будет создано для кластера или вы можете выбрать другое пользовательское расположение в кластере.
Вкладка "Поток данных" позволяет создавать и изменять потоки данных для экземпляра конвейера. Каждый поток данных содержит следующие сведения:
Параметры на этой вкладке описаны в следующей таблице.
Свойство
Описание
Имя.
Имя потока данных. Должен быть уникальным для этого конвейера.
Тип источника
Тип собираемых данных. В настоящее время поддерживаются следующие типы источников: — Системный журнал — OTLP
Порт
Порт, который конвейер прослушивает входящие данные. Если два потока данных используют один и тот же порт, они будут получать и обрабатывать данные.
Рабочая область Log Analytics
Рабочая область Log Analytics для отправки данных в.
Имя таблицы
Имя таблицы в рабочей области Log Analytics для отправки данных.
Настройка конвейера с помощью Azure CLI
Ниже приведены действия, необходимые для создания и настройки компонентов, необходимых для конвейера Azure Monitor на границе с помощью Azure CLI.
Расширение пограничного конвейера
Следующая команда добавляет расширение пограничного конвейера в кластер Kubernetes с поддержкой Arc.
Следующий шаблон ARM создает пользовательское расположение для кластера Kubernetes с поддержкой Arc.
az customlocation create --name <custom-location-name> --resource-group <resource-group-name> --namespace <name of namespace> --host-resource-id <connectedClusterId> --cluster-extension-ids <extensionId>
## Example
az customlocation create --name my-cluster-custom-location --resource-group my-resource-group --namespace my-cluster-custom-location --host-resource-id /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/Microsoft.Kubernetes/connectedClusters/my-cluster --cluster-extension-ids /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/Microsoft.Kubernetes/connectedClusters/my-cluster/providers/Microsoft.KubernetesConfiguration/extensions/my-cluster
DCE
Следующий шаблон ARM создает конечную точку сбора данных (DCE), необходимую для конвейера на границе для подключения к облачному конвейеру. Вы можете использовать существующий DCE, если у вас уже есть один в одном регионе. Замените свойства в следующей таблице перед развертыванием шаблона.
az monitor data-collection endpoint create -g "myResourceGroup" -l "eastus2euap" --name "myCollectionEndpoint" --public-network-access "Enabled"
## Example
az monitor data-collection endpoint create --name strato-06-dce --resource-group strato --public-network-access "Enabled"
DCR
DCR хранится в Azure Monitor и определяет способ обработки данных при получении из конвейера на краю. Конвейер в пограничной конфигурации указывает immutable ID DCR и stream В DCR, которые будут обрабатывать данные. Автоматически immutable ID создается при создании DCR.
Расположение DCR. Должен соответствовать расположению DCE.
dataCollectionEndpointId
Идентификатор ресурса DCE.
streamDeclarations
Схема полученных данных. Для каждого потока данных в конфигурации конвейера требуется один поток. Имя должно быть уникальным в DCR и должно начинаться с custom-. Разделы column в приведенных ниже примерах следует использовать для потоков данных OLTP и Syslog. Если схема целевой таблицы отличается, ее можно изменить с помощью преобразования, определенного в параметре transformKql .
destinations
Добавьте дополнительный раздел для отправки данных в несколько рабочих областей.
- name
Имя назначения для ссылки в dataFlows разделе. Должен быть уникальным для DCR.
- workspaceResourceId
Идентификатор ресурса рабочей области Log Analytics.
- workspaceId
Идентификатор рабочей области Log Analytics.
dataFlows
Соответствует потокам и назначениям. Одна запись для каждой комбинации потока и назначения.
- streams
Один или несколько потоков (определенных в streamDeclarations). Можно включить несколько потоков, если они отправляются в одно и то же место назначения.
- destinations
Одно или несколько назначений (определено в destinations). Можно включить несколько назначений, если они отправляются в одно и то же место назначения.
- transformKql
Преобразование, применяемое к данным перед отправкой в место назначения. Используйте source для отправки данных без каких-либо изменений. Выходные данные преобразования должны соответствовать схеме целевой таблицы. Дополнительные сведения о преобразованиях см . в преобразованиях сбора данных в Azure Monitor .
- outputStream
Указывает целевую таблицу в рабочей области Log Analytics. Таблица уже должна существовать в рабочей области. Для пользовательских таблиц префикс имени таблицы с помощью Custom-. Встроенные таблицы в настоящее время не поддерживаются конвейером в пограничном режиме.
az monitor data-collection rule create --name 'myDCRName' --location <location> --resource-group <resource-group> --rule-file '<dcr-file-path.json>'
## Example
az monitor data-collection rule create --name my-pipeline-dcr --location westus2 --resource-group 'my-resource-group' --rule-file 'C:\MyDCR.json'
Доступ К DCR
Кластер Kubernetes с поддержкой Arc должен иметь доступ к DCR для отправки данных в облачный конвейер. Чтобы получить идентификатор объекта назначенного системой удостоверения для кластера, используйте следующую команду.
az k8s-extension show --name <extension-name> --cluster-name <cluster-name> --resource-group <resource-group> --cluster-type connectedClusters --query "identity.principalId" -o tsv
## Example:
az k8s-extension show --name my-pipeline-extension --cluster-name my-cluster --resource-group my-resource-group --cluster-type connectedClusters --query "identity.principalId" -o tsv
Используйте выходные данные этой команды в качестве входных данных для следующей команды, чтобы предоставить конвейеру Azure Monitor полномочия для отправки телеметрии в DCR.
az role assignment create --assignee "<extension principal ID>" --role "Monitoring Metrics Publisher" --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Insights/dataCollectionRules/<dcr-name>"
## Example:
az role assignment create --assignee "00000000-0000-0000-0000-000000000000" --role "Monitoring Metrics Publisher" --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/Microsoft.Insights/dataCollectionRules/my-dcr"
Конфигурация конвейера Edge
Конфигурация пограничного конвейера определяет сведения о конвейере в пограничном экземпляре и развертывает потоки данных, необходимые для получения и отправки телеметрии в облако.
Замените свойства в следующей таблице перед развертыванием шаблона.
Свойство
Описание:
Общие сведения
name
Имя экземпляра конвейера. Должен быть уникальным в подписке.
location
Расположение экземпляра конвейера.
extendedLocation
Приемники
Одна запись для каждого получателя. Каждая запись указывает тип полученных данных, порт, который будет прослушиваться, и уникальное имя, которое будет использоваться в pipelines разделе конфигурации.
type
Тип полученных данных. Текущие параметры: OTLP и Syslog.
name
Имя получателя, на который ссылается в service разделе. Должен быть уникальным для экземпляра конвейера.
endpoint
Адрес и порт приемник прослушивает. Используется 0.0.0.0 для адресов al.
Должен быть уникальным для экземпляра конвейера. Имя используется в pipelines разделе конфигурации.
dataCollectionEndpointUrl
URL-адрес DCE, в котором конвейер в пограничном расположении отправит данные. Это можно найти в портал Azure, перейдя к DCE и скопировав значение приема журналов.
dataCollectionRule
Неизменяемый идентификатор DCR, определяющий коллекцию данных в облачном конвейере. В представлении JSON DCR в портал Azure скопируйте значение неизменяемого идентификатора в разделе "Общие".
- stream
Имя потока в DCR, которое будет принимать данные.
- maxStorageUsage
Емкость кэша. Когда достигается 80 % этой емкости, старые данные удаляются, чтобы освободить место для получения дополнительных данных.
- retentionPeriod
Период хранения в минутах. Данные будут отрезаются после этого периода времени.
- schema
Схема данных, отправляемых в облачный конвейер. Это должно соответствовать схеме, определенной в потоке в DCR. Схема, используемая в примере, допустима как для системного журнала, так и для OTLP.
Служба
Одна запись для каждого экземпляра конвейера. Рекомендуется использовать только один экземпляр для каждого расширения конвейера.
Конвейеры
Одна запись для каждого потока данных. Каждая запись совпадает receiver с элементом exporter.
name
Уникальное имя конвейера.
receivers
Один или несколько получателей, которые будут прослушивать получение данных.
processors
Зарезервировано для последующего использования.
exporters
Один или несколько экспортеров для отправки данных в облачный конвейер.
persistence
Имя постоянного тома, используемого для кэша. Удалите этот параметр, если вы не хотите включить кэш.
az deployment group create --resource-group <resource-group-name> --template-file <path-to-template>
## Example
az deployment group create --resource-group my-resource-group --template-file C:\MyPipelineConfig.json
Пример шаблона ARM для настройки всех компонентов
Вы можете развернуть все необходимые компоненты для конвейера Azure Monitor на границе с помощью одного шаблона ARM, показанного ниже. Измените файл параметров с определенными значениями для вашей среды. Каждый раздел шаблона описан ниже, включая разделы, которые необходимо изменить перед его использованием.
Компонент
Тип
Описание
Рабочая область Log Analytics
Microsoft.OperationalInsights/workspaces
Удалите этот раздел, если вы используете существующую рабочую область Log Analytics. Единственным параметром является имя рабочей области. Неизменяемый идентификатор рабочей области, который необходим для других компонентов, будет автоматически создан.
Конечная точка сбора данных (DCE)
Microsoft.Insights/dataCollectionEndpoints
Удалите этот раздел, если вы используете существующий DCE. Единственным обязательным параметром является имя DCE. URL-адрес приема журналов для DCE, который необходим для других компонентов, будет автоматически создан.
Расширение пограничного конвейера
Microsoft.KubernetesConfiguration/extensions
Единственным параметром является имя расширения конвейера.
Пользовательское расположение
Microsoft.ExtendedLocation/customLocations
Пользовательское расположение кластера Kubernetes с поддержкой Arc для создания пользовательского
Экземпляр пограничного конвейера
Microsoft.monitor/pipelineGroups
Экземпляр пограничного конвейера, включающий конфигурацию прослушивателя, экспортеров и потоков данных. Перед развертыванием шаблона необходимо изменить свойства экземпляра конвейера.
Правило сбора данных (DCR)
Microsoft.Insights/dataCollectionRules
Единственным параметром является имя DCR, но перед развертыванием шаблона необходимо изменить свойства DCR.
Проверка компонентов конвейера, выполняемых в кластере
В портал Azure перейдите в меню служб Kubernetes и выберите кластер Kubernetes с поддержкой Arc. Выберите службы и входящий трафик и убедитесь, что вы увидите следующие службы:
<имя> конвейера —external-service
<Служба имен> конвейера
Щелкните запись для <имени> конвейера external-service и запишите IP-адрес и порт в столбце Endpoints . Это внешний IP-адрес и порт, в который клиенты будут отправлять данные. Сведения о получении этого адреса от клиента см. в статье "Получение конечной точки входящего трафика".
Проверка пульса
Каждый конвейер, настроенный в экземпляре конвейера, будет отправлять запись Heartbeat пульса в таблицу в рабочей области Log Analytics каждую минуту. Содержимое столбца OSMajorVersion должно соответствовать имени экземпляра конвейера. Если в экземпляре конвейера есть несколько рабочих областей, будет использоваться первая настроенная.
Извлеките записи пульса с помощью запроса журнала, как показано в следующем примере:
Настройка клиента
После установки расширения и экземпляра пограничного конвейера необходимо настроить клиенты для отправки данных в конвейер.
Получение конечной точки входящего трафика
Для каждого клиента требуется внешний IP-адрес службы конвейера Azure Monitor. Используйте следующую команду, чтобы получить этот IP-адрес:
kubectl get services -n <namespace where azure monitor pipeline was installed>
Если приложение, создающее журналы, является внешним для кластера, скопируйте значение< внешнего IP-адреса для службы name-service или< имя>> конвейера-external-service с типом подсистемы балансировки нагрузки.
Если приложение находится в модуле pod в кластере, скопируйте значение cluster-ip .
Примечание.
Если для поля внешнего IP-адреса задано ожидание, необходимо настроить внешний IP-адрес для этого входящего трафика вручную в соответствии с конфигурацией кластера.
Клиент
Description
Системный журнал
Обновите клиенты Syslog, чтобы отправлять данные в конечную точку конвейера и порт потока данных Системного журнала.
OTLP
Пограничный конвейер Azure Monitor предоставляет конечную точку OTLP на основе gRPC через порт 4317. Настройка инструментирования для отправки в эту конечную точку OTLP будет зависеть от самой библиотеки инструментирования. См . документацию по конечной точке OTLP или сборщику для OpenTelemetry. Метод переменной среды задокументирован в конфигурации экспортера OTLP.
Проверка данных
Заключительным шагом является проверка получения данных в рабочей области Log Analytics. Эту проверку можно сделать, выполнив запрос в рабочей области Log Analytics, чтобы получить данные из таблицы.