Настройка локальной среды выполнения интеграции (SHIR) для сбора данных Log Analytics
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
Фабрика данных Azure Azure Synapse Analytics
Совет
Попробуйте использовать фабрику данных в Microsoft Fabric, решение для аналитики с одним интерфейсом для предприятий. Microsoft Fabric охватывает все, от перемещения данных до обработки и анализа данных в режиме реального времени, бизнес-аналитики и отчетности. Узнайте, как бесплатно запустить новую пробную версию !
Необходимые компоненты
Для этого подхода требуется доступная рабочая область Log Analytics. Мы рекомендуем знать идентификатора рабочей области и ключа проверки подлинности рабочей области Log Analytics, так как эти данные могут понадобиться для определенных сценариев. Это решение увеличит объем данных, которые будут отправлены в рабочую область Log Analytics, и будет иметь небольшое влияние на общую стоимость. Сведения о том, как свести объем данных к минимуму, см. в статье.
Цели и сценарии
Централизуйте события и данные счетчиков производительности в рабочей области Log Analytics. В первую очередь необходимо надлежащим образом инструментировать виртуальную машину, на которой размещена SHIR. Выберите один из двух основных сценариев ниже.
Инструментирование локальных виртуальных машин
В статье Установка агента Log Analytics на компьютерах Windows описано, как установить клиент на виртуальную машину, обычно размещенную в локальной среде. Это может быть либо физический сервер, либо виртуальная машина, размещенная на управляемой клиентом низкоуровневой оболочке. Как упоминалось в разделе предварительных требований, при установке агента Log Analytics необходимо указать идентификатор и ключ рабочей области Log Analytics, чтобы завершить подключение.
Инструментирование виртуальных машин Azure
Рекомендуемый подход к инструментированию SHIR на базе виртуальной машины Azure заключается в использовании аналитики виртуальной машины, как описано в статье Включение обзора аналитических сведений виртуальных машин Azure. Настроить агент Log Analytics можно несколькими способами, когда SHIR размещается на виртуальной машине Azure. Все параметры описаны в статье Общие сведения об агенте Log Analytics.
Настройка журнала событий и счетчика производительности
На этом шаге будет показано, как настроить отправку журналов просмотра событий и счетчиков производительности в Log Analytics. Описанные ниже действия являются общими независимо от способа развертывания агента.
Выбор журналов просмотра событий
Сначала необходимо собрать журналы просмотра событий, относящиеся к SHIR, как описано в статье Сбор источников данных журналов событий Windows с помощью агента Log Analytics в Azure Monitor.
Важно отметить, что при выборе журналов событий с помощью интерфейса в обычных условиях не будут отображаться все журналы, которые могут существовать на компьютере. Поэтому два журнала, необходимые для мониторинга SHIR, не будут отображаться в этом списке. Если ввести имя журнала точно так же, как оно отображается на локальной виртуальной машине, он будет захвачен и отправлен в рабочую область Log Analytics.
Имя журнала событий, которое необходимо настроить:
- Соединители — среда выполнения интеграции
- Integration Runtime
Внимание
Если не установить флажок уровня информации, объем данных увеличится, если развернуто много узлов SHIR и имеется большое количество сканирований. Мы настоятельно рекомендуем указать только ошибки и предупреждения.
Выбор счетчиков производительности
В той же области конфигурации можно щелкнуть Счетчики производительности Windows, чтобы выбрать отдельные счетчики производительности для отправки в Log Analytics.
Внимание
Помните, что счетчики производительности — это по сути непрерывный поток данных. Поэтому важно учитывать влияние сбора данных на общую стоимость развертывания Azure Monitor и Log Analytics. Если разрешенный бюджет приема данных не предоставлен, а постоянный прием данных был разрешен и включен в бюджет, при сборе счетчиков производительности следует настроить только определенный период для определения базовых показателей производительности.
В интерфейсе при первой настройке рекомендуется использовать предложенный набор счетчиков. Выберите те, которые относятся к типу требуемого анализа производительности. % ЦП и доступная память, как правило, отслеживаются, а другие счетчики, такие как использование пропускной способности сети, могут быть полезны в сценариях с большим объемом данных и ограниченными пропускной способностью или временем выполнения.
Просмотр событий и данных счетчиков производительности в Log Analytics
Чтобы узнать, как анализировать данные мониторинга в хранилище журналов Azure Monitor или Log Analytics с помощью языка запросов Kusto (KQL), см . запросы Kusto.
Две таблицы, в которых сохраняются данные телеметрии, называются производительностью и событием соответственно. Следующий запрос проверяет количество строк, чтобы узнать, есть ли в ней поток данных. Это подтверждает, работает ли инструментирование, описанное выше.
Примеры запросов KQL
Проверка количества строк
(
Event
| extend TableName = "Event"
| summarize count() by TableName
)
| union
(
Perf
| extend TableName = "Perf"
| summarize count() by TableName
)
События запроса
Получение первых 10 строк событий
Event
| take 10
Получение числа событий по серьезности сообщения
Event
| summarize count() by EventLevelName
Отображение круговой диаграммы количества событий по уровню серьезности сообщения
Event
| summarize count() by EventLevelName
| render piechart
Получение всех ошибок с определенной текстовой строкой
Здесь выполняется поиск всех сообщений со словом них отключено в них.
Event
| where RenderedDescription has "disconnected"
Поиск ключевого слова в нескольких таблицах без знания схемы
Команда search полезна, когда неизвестно, в каком столбце содержатся сведения. Этот запрос возвращает все строки из указанных таблиц, которые содержат по крайней мере один столбец, содержащий искомый термин. В этом примере слово disconnected (отключено).
search in (Perf, Event) "disconnected"
Получение всех событий из одного конкретного журнала
В этом примере мы сужаем запрос к журналу журналов с именем Connectors — Integration Runtime.
Event
| where EventLog == "Connectors - Integration Runtime"
Использование временного диапазона для ограничения результатов запроса
Этот запрос использует тот же запрос, что и выше, но ограничит результаты до тех, которые происходят в течение 2 дней назад или раньше.
Event
| where EventLog == "Connectors - Integration Runtime"
and TimeGenerated >= ago(2d)
Запрос данных счетчика производительности
Получение первых 10 считываний счетчиков производительности
Perf
| take 10
Получение определенного счетчика с ограничениями по времени
Perf
| where TimeGenerated >= ago(24h)
and ObjectName == "Network Adapter"
and InstanceName == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
and CounterName == "Bytes Received/sec"
Счетчики производительности являются иерархическими, поэтому в запросе должно было достаточно предикатов места, чтобы выбрать только конкретный счетчик.
Получение 95 процентиля для данного счетчика с интервалом 30 минут за последние 24 часа
Этот пример представляет все счетчики для определенного сетевого адаптера.
Perf
| where TimeGenerated >= ago(24h)
and ObjectName == "Network Adapter"
and InstanceName == "Mellanox ConnectX-4 Lx Virtual Ethernet Adapter"
| project TimeGenerated, Computer, ObjectName, InstanceName, CounterName, CounterValue
| summarize percentile(CounterValue, 95) by bin(TimeGenerated, 30m), Computer, ObjectName, InstanceName, CounterName
Использование переменных для повторного использования кода
Мы создаем переменную имя объекта и имя счетчика, поэтому нам не нужно изменять текст запроса KQL, чтобы внести изменения в эти параметры позже.
let pObjectName = "Memory"; // Required to select the right counter
let pCounterName = "Available MBytes"; // Required to select the right counter
Perf
| where Type == "Perf" and ObjectName == pObjectName and CounterName == pCounterName
| project TimeGenerated, Computer, CounterName, CounterValue
| order by TimeGenerated asc
| summarize Value=max(CounterValue) by CounterName, TimeStamps=TimeGenerated