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

Сбор текстовых журналов с помощью агента Log Analytics в Azure Monitor

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

Это важно

В этой статье описывается, как собирать текстовый журнал с помощью агента Log Analytics. Если вы используете агент Azure Monitor, см. статью "Сбор текстовых журналов с помощью агента Azure Monitor".

Это важно

Устаревший агент Log Analyticsустарел с 31 августа 2024 г. Корпорация Майкрософт больше не будет предоставлять поддержку агента Log Analytics. Если вы используете агент Log Analytics для приема данных в Azure Monitor, перейдите к агенту Azure Monitor.

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

Собранные файлы журнала должны соответствовать следующим критериям:

  • Журнал должен иметь одну запись для каждой строки или использовать метку времени, соответствующую одному из следующих форматов в начале каждой записи:

    ДД.MM.ГГГГ ЧЧ:ММ:СС
    M/D/YYYY HH:MM:SS AM/PM
    Пн ДД.ММ.ГГГГ ЧЧ:ММ:СС
    yYMMdd HH:mm:ss
    ddMMyy HH:mm:ss
    MMM d hh:mm:ss
    dd.MM.yyyy:HH:mm:ss zzz
    гггг-ММ-ддTHH:MM:ssK

  • Файл журнала не должен разрешать циклическое ведение журнала. Это изменение журнала, в котором файл перезаписывается с новыми записями или файл переименован, а имя файла повторно используется для продолжения ведения журнала.

  • Файл журнала должен использовать кодировку ASCII или UTF-8. Другие форматы, например, UTF-16, не поддерживаются.

  • Для Linux преобразование часового пояса не поддерживается для меток времени в журналах.

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

Замечание

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

Рабочая область Log Analytics поддерживает следующие ограничения:

  • Можно создать только 500 пользовательских журналов.
  • Таблица поддерживает только до 500 столбцов.
  • Максимальное число символов для имени столбца — 500.

Это важно

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

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

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

Откройте мастер пользовательского журнала

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

  1. На портале Azure выберите рабочие области Log Analytics> свою рабочую область >Таблицы.

  2. Выберите Создать и затем Новый настраиваемый журнал (на основе MMA).

    По умолчанию все изменения конфигурации автоматически отправляются всем агентам. Для агентов Linux файл конфигурации отправляется сборщику данных Fluentd.

Загрузка и анализ образца логов

Чтобы начать, отправьте пример пользовательского журнала. Мастер анализирует и отображает записи в этом файле для проверки. Azure Monitor будет использовать разделитель, указанный для идентификации каждой записи.

Новая строка — это разделитель по умолчанию и используется для файлов журналов, имеющих одну запись для каждой строки. Если строка начинается с даты и времени в одном из доступных форматов, можно указать разделитель меток времени , который поддерживает записи, охватывающие несколько строк.

Если используется разделитель меток времени, свойство TimeGenerated каждой записи, хранящейся в Azure Monitor, будет заполнено датой и временем, указанными для этой записи в файле журнала. Если используется новый разделитель строк, TimeGenerated заполняется датой и временем сбора записи в Azure Monitor.

  1. Выберите «Обзор» и перейдите к образцу файла. Эта кнопка может быть помечена как "Выбрать файл " в некоторых браузерах.

  2. Нажмите кнопку Далее.

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

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

  4. Нажмите кнопку Далее.

Добавьте пути сбора журналов

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

Например, приложение может создавать файл журнала каждый день с датой, включенной в имя, как в log20100316.txt. Шаблон для такого журнала может быть журнал*.txt, который будет применяться к любому файлу журнала после схемы именования приложения.

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

Description Путь
Все файлы в C:\Logs с расширением .txt в агенте Windows C:\Logs\*.txt
Все файлы в C:\Logs с именем, начинающимся с "log" и расширением .txt на агенте Windows C:\Logs\log*.txt
Все файлы в файле /var/log/audit с расширением .txt в агенте Linux /var/log/audit/*.txt
Все файлы в каталоге /var/log/audit, название которых начинается с "log" и заканчивается на расширение .txt, на агенте Linux. /var/log/audit/log*.txt
  1. Выберите Windows или Linux, чтобы указать, какой формат пути вы добавляете.
  2. Введите путь и нажмите кнопку + .
  3. Повторите процесс для любых оставшихся путей.

Укажите имя и описание журнала

Указанное имя будет использоваться для типа журнала, как описано. Он всегда заканчивается _CL, чтобы указать, что это пользовательский журнал.

  1. Введите имя журнала. Суффикс _CL автоматически предоставляется.
  2. Добавьте необязательное описание.
  3. Нажмите кнопку "Далее ", чтобы сохранить настраиваемое определение журнала.

Проверка сбора пользовательских журналов

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

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

Замечание

Если свойство RawData отсутствует в запросе, может потребоваться закрыть и повторно открыть браузер.

Разбор пользовательских записей журнала

Вся запись журнала будет храниться в одном свойстве с именем RawData. Скорее всего, вы хотите разделить различные фрагменты информации в каждой записи в отдельные свойства для каждой записи. Для параметров разбора RawData на несколько свойств, смотрите Разбор текстовых данных в Azure Monitor.

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

См. статью "Удалить таблицу".

Сбор данных

Azure Monitor собирает новые записи из каждого пользовательского журнала примерно каждые 5 минут. Агент записывает свое местоположение в каждом файле журнала, из которого он собирает данные. Если агент переходит в автономный режим на некоторое время, Azure Monitor продолжает собирать записи с того места, где он остановился, даже если эти записи были созданы, пока агент был офлайн.

Все содержимое записи журнала записывается в одно свойство с именем RawData. Методы анализа каждой импортированной записи журнала в несколько свойств см. в разделе "Анализ текстовых данных" в Azure Monitor.

Свойства пользовательской записи журнала

Пользовательские записи журнала имеют тип с именем журнала, которое вы указываете, и свойствами в следующей таблице.

Недвижимость Description
Время генерации Дата и время, когда запись была собрана с помощью Azure Monitor. Если в журнале используется разделитель на основе времени, это время, полученное из записи.
Система источников Тип агента, из который была собрана запись.
OpsManager — агент Windows, прямое подключение или System Center Operations Manager
Linux — все агенты Linux
Исходные данные Полный текст собранной записи. Скорее всего, вы захотите разобрать эти данные на отдельные свойства.
ИмяГруппыУправления Название группы управления для агентов System Center Operations Manager. Для других агентов это имя — идентификатор< AOI-workspace>.

Пример пошагового руководства по добавлению пользовательского журнала

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

2019-08-27 01:34:36 207,Success,Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected
2019-08-27 01:33:33 208,Warning,Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
2019-08-27 01:35:44 209,Success,Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
2019-08-27 01:38:22 302,Error,Application could not connect to database
2019-08-27 01:31:34 303,Error,Application lost connection to database

Загрузка и анализ примера журнала

Мы предоставляем один из файлов журнала и можем видеть события, которые он будет собирать. В этом случае новая строка является достаточным разделителем. Если одна запись в журнале может охватывать несколько строк, однако потребуется использовать разделитель меток времени.

Снимок экрана, который показывает загрузку и анализ примера журнала.

Добавьте пути сбора журналов

Файлы журнала будут находиться в папке C:\MyApp\Logs. Новый файл будет создан каждый день с именем, включающим дату в шаблоне appYYYYMMDD.log. Достаточно шаблоном для этого журнала будет C:\MyApp\Logs\*.log.

Снимок экрана, показывающий добавление пути к сбору журнала.

Укажите имя и описание журнала

Мы используем имя MyApp_CL и введем его в разделе Описание.

Снимок экрана: добавление имени журнала.

Проверка сбора пользовательских журналов

Мы используем простой запрос MyApp_CL для возврата всех записей из собранного журнала.

Снимок экрана: запрос журнала без настраиваемых полей.

Альтернативные варианты пользовательских журналов

Хотя пользовательские журналы полезны, если данные соответствуют указанным критериям, существуют случаи, когда вам нужна другая стратегия:

  • Данные не соответствуют требуемой структуре, например метке времени в другом формате.
  • Файл журнала не соответствует требованиям, таким как кодировка файлов или неподдерживаемая структура папок.
  • Перед сбором данных требуется предварительная обработка или фильтрация.

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

Дальнейшие шаги

  • Last updated on