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

Мониторинг операционных проблем в рабочей области Azure Monitor Log Analytics

  • Статья

Чтобы обеспечить производительность и доступность рабочей области Log Analytics в Azure Monitor, необходимо иметь возможность упреждающего обнаружения возникающих проблем. В этой статье описывается, как отслеживать работоспособность рабочей области Log Analytics с помощью данных в таблице операций. Эта таблица включена в каждую рабочую область Log Analytics. Он содержит сообщения об ошибках и предупреждения, происходящие в рабочей области. Рекомендуется создавать оповещения для проблем с уровнем предупреждения и ошибки.

Требуемые разрешения

У вас должны быть Microsoft.OperationalInsights/workspaces/query/*/read разрешения на запрашиваемые рабочие области Log Analytics, как указано встроенной ролью Log Analytics Reader, например.

Функция _LogOperation

Журналы Azure Monitor отправляют сведения о любых проблемах в таблицу операций в рабочей области, в которой возникла проблема. Системная _LogOperation функция основана на таблице операций и предоставляет упрощенный набор сведений для анализа и оповещения.

Столбцы

Функция _LogOperation возвращает столбцы в следующей таблице.

Столбец Description
TimeGenerated Время возникновения инцидента (в формате UTC).
Категория Группа категорий операций. Может использоваться для фильтрации по типам операций и создания более точного аудита системы и оповещения. Список категорий см. в следующем разделе.
Операция Описание типа операции. Операция может указывать на то, что достигнут один из ограничений Log Analytics, связанная с внутренним процессом или любым другим сообщением службы.
Уровень Степень серьезности ошибки
- Info: особое внимание не требуется.
- Предупреждение: процесс не был выполнен должным образом, и необходимо внимание.
— Ошибка: произошел сбой процесса и требуется внимание.
Подробный сведения Подробное описание операции включает конкретное сообщение об ошибке.
_ResourceId Идентификатор ресурса Azure, связанного с операцией.
Компьютер Имя компьютера, если операция связана с агентом Azure Monitor.
CorrelationId Используется для группирования последовательных связанных операций.

Категории

В следующей _LogOperation таблице описываются категории из функции.

Категория Description
Прием (Ingestion) Операции, которые являются частью процесса приема данных.
Агент Указывает на ошибку при установке агента.
сбор данных Операции, связанные с процессами сбора данных.
Целевые решения Операция типа ConfigurationScope была обработана.
Решение "Оценка" Выполнен процесс оценки.

Прием (Ingestion)

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

Внимание

Если вы устраняете неполадки сбора данных для сценария, использующего правило сбора данных (DCR), например агент Azure Monitor или API приема журналов, см . статью "Мониторинг и устранение неполадок" сбора данных DCR в Azure Monitor для получения дополнительных сведений об устранении неполадок.

Операция: сбор данных остановлен

"Сбор данных остановлен, так как достигнуто дневное ограничение бесплатного сбора данных. Состояние приема = OverQuota"

За последние семь дней коллекция журналов достигла ежедневно заданного ограничения. Ограничение устанавливается либо так, как для рабочей области задан уровень "Бесплатный" , либо для этой рабочей области настроено ограничение ежедневной коллекции. После того как коллекция данных достигнет заданного ограничения, она автоматически останавливается в течение дня и возобновляется только в течение следующего дня сбора.

Рекомендуемые действия:

  • Проверьте таблицу _LogOperation для остановленных сборов и возобновления сбора событий:
    _LogOperation | where TimeGenerated >= ago(7d) | where Category == "Ingestion" | where Detail has "Data collection"
  • Создайте оповещение о событии операции "Сбор данных остановлено". Это оповещение уведомляет вас о достижении ограничения коллекции.
  • Данные, собранные после достижения ежедневного ограничения сбора, будут потеряны. Используйте область "Аналитика рабочей области" для просмотра показателей использования из каждого источника. Или вы можете управлять максимальным объемом данных ежедневно или изменять ценовую категорию на ту, которая соответствует шаблону ставок сбора.
  • Скорость сбора данных вычисляется в день и сбрасывается в начале следующего дня. Вы также можете отслеживать событие возобновления сбора, создав оповещение о событии операции "Сбор данных возобновлено".

Операция: скорость приема данных

"В рабочей области превышено ограничение на объем принимаемых данных в день: {0:0.00} МБ в минуту и данные были удалены".

Рекомендуемые действия:

  • _LogOperation Проверьте таблицу для события частоты приема:

    _LogOperation | where TimeGenerated >= ago(7d) | where Category == "Ingestion" | where Operation has "Ingestion rate" событие отправляется в таблицу операций в рабочей области каждые шесть часов, пока пороговое значение продолжает превышаться.
  • Создайте оповещение о событии операции "Сбор данных остановлено". Это оповещение уведомляет вас о достижении ограничения.
  • Данные, собранные во время приема, достигли 100 процентов, будут удалены и потеряны. Используйте область "Аналитика рабочей области", чтобы просмотреть шаблоны использования и попытаться уменьшить их.
    Дополнительные сведения см. в следующем разделе:

Операция: максимальное число столбцов в таблице

"Тип данных <имя таблицы> был удален, так как число полей <число новых полей> превышает предельное число <текущее предельное число полей> настраиваемых полей на один тип данных."

Рекомендуемое действие. Для пользовательских таблиц можно перейти к анализу данных в запросах.

Операция: проверка содержимого поля

"Значения следующих полей <имя поля> типа <имя таблицы> были обрезаны до максимального разрешенного размера в <предельное значение размера поля> байт. Измените входные данные соответствующим образом."

Поле, превышающее размер ограничения, было обработано журналами Azure. Поле было обрезано до допустимого предела поля. Мы не рекомендуем отправлять поля, превышающие допустимое ограничение, так как это приводит к потере данных.

Рекомендуемые действия:

Проверьте источник затронутого типа данных:

  • Если данные отправляются через API сборщика данных HTTP, необходимо изменить код\скрипт, чтобы разделить данные перед приемом.
  • Для пользовательских журналов, собранных агентом Log Analytics, измените параметры ведения журнала приложения или средства.
  • Для других типов данных создайте обращение в службу поддержки. Дополнительные сведения см. в статье Ограничения службы Azure Monitor.

сбор данных

В следующем разделе содержатся сведения о сборе данных.

Операция: сбор журналов действий Azure

"Доступ к подписке был утерян. Убедитесь, что подписка на идентификатор> подписки находится в клиенте> <Microsoft Entra идентификатора клиента.< Если подписка передается другому клиенту, это не влияет на службы, но информация о клиенте может занять до часа для распространения".

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

Рекомендуемые действия:

  • Если подписка, указанная в сообщении предупреждения, больше не существует, перейдите в область соединителя журнала устаревших действий в разделе "Классический". Выберите соответствующую подписку и нажмите кнопку "Отключить ".
  • Если у вас больше нет доступа к подписке, указанной в сообщении предупреждения:
    • Выполните предыдущий шаг, чтобы отключить подписку.
    • Чтобы продолжить сбор журналов из этой подписки, обратитесь к владельцу подписки, чтобы исправить разрешения и повторно включить коллекцию журналов действий.
  • Создайте параметр диагностики для отправки журнала действий в рабочую область Log Analytics.

Агент

В следующем разделе содержатся сведения об агентах.

Операция: агент Linux

"Сбой двух последовательных приложений конфигурации из параметров OMS".

Параметры конфигурации на портале изменились.

Рекомендуемое действие. Эта проблема возникает в случае, если у агента возникает проблема для получения новых параметров конфигурации. Чтобы устранить эту проблему, переустановите агент. Проверьте таблицу _LogOperation события агента:

_LogOperation | where TimeGenerated >= ago(6h) | where Category == "Agent" | where Operation == "Linux Agent" | distinct _ResourceId

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

Правила оповещения

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

Рекомендуемая стратегия состоит в том, чтобы начать с двух правил генерации оповещений на основе уровня проблемы. Используйте короткий интервал, например каждые 5 минут, для ошибок, и более длинную периодичность, например 24 часа, для предупреждений. Так как ошибки указывают на потенциальную потерю данных, необходимо быстро реагировать на них, чтобы свести к минимуму любую потерю. Предупреждения обычно указывают на проблему, которая не требует немедленного внимания, поэтому их можно просматривать ежедневно.

Используйте процесс создания , просмотра оповещений поиска журналов и управления ими с помощью Azure Monitor для создания правил генерации оповещений поиска по журналам. В следующих разделах приведены подробные сведения о каждом правиле.

Query Пороговое значение Период Периодичность
_LogOperation | where Level == "Error" 0 5 5
_LogOperation | where Level == "Warning" 0 1,440 1,440

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

Чтобы создать правило генерации оповещений для определенной операции, используйте запрос, включающий столбцы Категория и Операции.

В следующем примере создается оповещение "Предупреждение", когда скорость приема томов достигла 80 процентов ограничения:

  • Цель: выберите рабочую область Log Analytics
  • Критерии:
    • Название сигнала: "Пользовательский поиск по журналам".
    • Поисковый запрос: _LogOperation | where Category == "Ingestion" | where Operation == "Ingestion rate" | where Level == "Warning"
    • Основа: число результатов.
    • Условие: "больше чем".
    • Пороговое значение: 0.
    • Период: 5 (в минутах).
    • Периодичность: 5 (в минутах).
  • Название правила генерации оповещений: "Достигнуто ежедневное ограничение сбора данных".
  • Серьезность: предупреждение (серьезность 1).

В следующем примере создается оповещение "Предупреждение", когда коллекция данных достигла ежедневного ограничения:

  • Цель: выберите рабочую область Log Analytics
  • Критерии:
    • Название сигнала: "Пользовательский поиск по журналам".
    • Поисковый запрос: _LogOperation | where Category == "Ingestion" | where Operation == "Data collection Status" | where Level == "Warning"
    • Основа: число результатов.
    • Условие: "больше чем".
    • Пороговое значение: 0.
    • Период: 5 (в минутах).
    • Периодичность: 5 (в минутах).
  • Название правила генерации оповещений: "Достигнуто ежедневное ограничение сбора данных".
  • Серьезность: предупреждение (серьезность 1).

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