Сбор текстового файла из виртуальной машины с помощью Azure Monitor

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

Сведения о создании DCR приведены в статье "Сбор данных из клиента виртуальной машины" с помощью Azure Monitor. В этой статье содержатся дополнительные сведения о типе источника данных пользовательских текстовых журналов.

Предпосылки

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

Настройка пользовательского источника данных текстового файла

Создайте DCR с помощью процесса сбора данных из клиента виртуальной машины с помощью Azure Monitor. На вкладке "Сбор и доставка " DCR выберите настраиваемые текстовые журналы в раскрывающемся списке типа источника данных .

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

Добавить пункты назначения

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

Форматы времени

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

Требования к текстовым файлам и рекомендации

Файл, собираемый Azure Monitor, должен соответствовать следующим требованиям:

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

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

2024-06-21 19:17:34,1423,Error,Sales,Unable to connect to pricing service.
2024-06-21 19:18:23,1420,Information,Sales,Pricing service connection established.
2024-06-21 21:45:13,2011,Warning,Procurement,Module failed and was restarted.
2024-06-21 23:53:31,4100,Information,Data,Nightly backup complete.

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

• Не нацеливайте более 10 каталогов с файлами журналов. Опрос слишком большого количества каталогов приводит к ухудшению производительности.
• Непрерывно очищайте файлы журналов в отслеживаемом каталоге. Отслеживание большого количества файлов журналов может ускорить использование ЦП и памяти агента. Подождите по крайней мере два дня, чтобы обеспечить достаточно времени для обработки всех журналов.
• Не переименуйте файл, соответствующий шаблону сканирования файлов, другому имени, который также соответствует шаблону сканирования файлов. Это приведет к загрузке повторяющихся данных.
• Не переименуйте или не копируйте большие файлы журнала, соответствующие шаблону сканирования файлов в отслеживаемый каталог. Если необходимо, не превышать 50 МБ в минуту.

Таблица рабочей области Log Analytics

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

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

¹ Таблица не обязательно включает RawData столбец, если для анализа данных в нескольких столбцах используется преобразование.

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

Создание настраиваемой таблицы

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

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

$tableParams = @'
{
    "properties": {
        "schema": {
               "name": "{TableName}_CL",
               "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "DateTime"
                    }, 
                    {
                        "name": "Computer",
                        "type": "string"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "RawData",
                        "type": "string"
                    }
              ]
        }
    }
}
'@

Invoke-AzRestMethod -Path "/subscriptions/{subscription}/resourcegroups/{resourcegroup}/providers/microsoft.operationalinsights/workspaces/{workspace}/tables/MyTable_CL?api-version=2021-12-01-preview" -Method PUT -payload $tableParams

Многострочные файлы журналов

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

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

2024-06-21 19:17:34,1423,Error,Sales,
Unable to connect to pricing service.
2024-06-21 19:18:23,1420,Information,Sales,
Pricing service connection established.
2024-06-21 21:45:13,2011,Warning,Procurement,
Module failed and was restarted.
2024-06-21 23:53:31,4100,Information,Data,
Nightly backup complete.

Если формат YYYY-MM-DD HH:MM:SS метки времени используется в DCR, данные будут собираться так же, как и в предыдущем примере. Дополнительные строки будут включены в RawData столбец. Если использовался другой формат метки времени, который не соответствует дате в записи журнала, каждая запись будет собираться в виде двух отдельных записей.

Файлы журналов с разделителями

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

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

Ниже приведены важные сведения о запросе преобразования:

• Запрос выводит свойства, соответствующие имени столбца в целевой таблице.
• В этом примере свойство в файле журнала переименовывается Time таким образом, чтобы это значение использовалось для TimeGenerated. Если это не было предоставлено, то TimeGenerated было бы заполнено временем загрузки.
• Так как split возвращает динамические данные, необходимо использовать такие функции, как tostring и toint для преобразования данных в правильный скалярный тип.

source | project d = split(RawData,",") | project TimeGenerated=todatetime(d[0]), Code=toint(d[1]), Severity=tostring(d[2]), Module=tostring(d[3]), Message=tostring(d[4])

Получение этих данных с помощью запроса журнала вернет следующие результаты.

Устранение неполадок

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

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

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

• Дополнительные сведения об агенте Azure Monitor.
• Подробнее о правилах сбора данных.