Настройка локальной среды выполнения интеграции (SHIR) для коллекции log analytics

ПРИМЕНИМО К: Фабрика данных Azure Azure Synapse Analytics

Tip

Data Factory в Microsoft Fabric — это следующее поколение Фабрика данных Azure с более простой архитектурой, встроенным ИИ и новыми функциями. Если вы не знакомы с интеграцией данных, начните с Fabric Data Factory. Существующие рабочие нагрузки ADF могут обновляться до Fabric для доступа к новым возможностям в области обработки и анализа данных, аналитики в режиме реального времени и отчетов.

Prerequisites

Для этого подхода требуется имеющаяся рабочая область Log Analytics. Мы рекомендуем запишите идентификатор рабочей области и ключ проверки подлинности вашей Log Analytics рабочей области, так как это может потребоваться для определенных сценариев. Это решение увеличит данные, которые будут отправляться в рабочую область Log Analytics и будут иметь небольшое влияние на общую стоимость. Прочитайте подробности о том, как свести объем данных к минимуму.

Цели и сценарии

Для централизации событий и данных счетчика производительности в рабочей области Log Analytics, сначала необходимо правильно инструментировать виртуальную машину, на которой размещен SHIR. Выберите один из двух основных сценариев ниже.

Инструментирование локальных виртуальных машин

В статье Install Log Analytics агент на компьютерах Windows описывается, как установить клиент на виртуальной машине, размещенной в локальной среде. Это может быть физический сервер или виртуальная машина, размещенная на управляемом клиентом гипервизоре. Как упоминалось в разделе предварительных требований, при установке агента Log Analytics необходимо предоставить идентификатор рабочей области Log Analytics и ключ рабочей области для завершения подключения.

Инструментирование виртуальных машин Azure

Рекомендуемый подход к инструментированию автономного интеграционного шлюза, развернутого на виртуальной машине Azure, — использовать аналитику виртуальных машин, как описано в статье Обзор аналитики виртуальных машин. Существует несколько способов настройки агента Log Analytics при размещении SHIR в виртуальной машине Azure. Все параметры описаны в статье «Обзор агента Log Analytics».

Настройка записи журнала событий и счетчика производительности

На этом шаге показано, как настроить журналы просмотра событий и счетчики производительности для отправки в Log Analytics. Описанные ниже действия являются общими независимо от того, как был развернут агент.

Выбор журналов средства просмотра событий

Сначала вы должны собрать журналы просмотра событий, относящиеся к SHIR, как описано в статье Сбор источников данных журнала событий Windows с агентом Log Analytics в Azure Monitor.

Важно отметить, что при выборе журналов событий с помощью интерфейса обычно вы не увидите все журналы, которые могут существовать на компьютере. Таким образом, два журнала, которые нам нужны для мониторинга SHIR, не будут отображаться в этом списке. Если ввести имя журнала точно так же, как оно отображается на локальной виртуальной машине, оно будет записано и отправлено в рабочую область Log Analytics.

Имя журнала событий, которое необходимо настроить:

  • Соединители — Среда выполнения интеграции
  • Среда выполнения интеграции

Снимок экрана: выбор соответствующих журналов SHIR с ошибками и предупреждениями.

Важно

Оставив уровень сведений отмеченным, вы значительно увеличите объем данных, если у вас развернуто много узлов SHIR и большое количество сканирований. Мы настоятельно рекомендуем сохранить только Ошибку и Предупреждение.

Выбор счетчиков производительности

В той же области конфигурации можно щелкнуть Windows Счетчики Производительности, чтобы выбрать отдельные счетчики производительности для отправки в систему аналитики журналов.

Важно

Имейте в виду, что счетчики производительности являются, по своей природе, непрерывным потоком данных. Поэтому важно учитывать влияние сбора данных на общую стоимость развертывания Azure Monitor/Log Analytics. Если не предоставлен бюджет на прием данных, а постоянный прием данных не был разрешен и включен в бюджет, то сбор счетчиков производительности следует настраивать только на определенный период, чтобы установить базовые показатели производительности.

При первой настройке интерфейса рекомендуется использовать предлагаемый набор счетчиков. Выберите те, которые применяются к типу анализа производительности, который требуется выполнить. %CPU и доступная память обычно отслеживаются счетчиками, но другие, такие как потребление пропускной способности сети , может быть полезно в сценариях, когда объем данных большой, а пропускная способность или время выполнения ограничены.

Снимок экрана интерфейса выбора счетчика в портале Azure.

Просмотр данных о событиях и счетчиках производительности в Log Analytics

Сведения об анализе данных мониторинга в хранилище журналов Azure Monitor / Log Analytics с помощью языка запросов Kusto (KQL) см. в статье Kusto querys.

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

Примеры запросов 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 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