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

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

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

Предпосылки

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

Настройка настраиваемого источника данных JSON-файла

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

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

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

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

Требования к json-файлам и рекомендации

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

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

Ниже приведен пример типичного файла журнала JSON, который можно собрать с помощью Azure Monitor. К ним относятся поля: Time, Code, Severity,Module и Message.

{"Time":"2025-03-07 13:17:34","Code":1423,"Severity":"Error","Module":"Sales","Message":"Unable to connect to pricing service."}
{"Time":"2025-03-07 13:18:23","Code":1420,"Severity":"Information","Module":"Sales","Message":"Pricing service connection established."}
{"Time":"2025-03-07 15:45:13","Code":2011,"Severity":"Warning","Module":"Procurement","Message":"Module failed and was restarted."}
{"Time":"2025-03-07 15:53:31","Code":4100,"Severity":"Information","Module":"Data","Message":"Daily backup complete."}

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

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

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

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

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

В следующем примере показан запрос, возвращающий данные из таблицы, созданной для примера JSON-файла, показанного выше. Он был собран с помощью DCR с примером схемы JSON, показанной выше. Поскольку данные JSON не включают свойство для TimeGenerated, используется время приема данных. Столбцы Computer и FilePath также заполняются автоматически.

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

Если целевая таблица еще не существует, необходимо создать ее перед созданием DCR. См. статью "Создание настраиваемой таблицы" для ознакомления с различными методами создания таблицы. Например, можно использовать следующий скрипт PowerShell для создания настраиваемой таблицы для получения данных из примера JSON-файла выше. В этом примере также добавляются необязательные столбцы.

$tableParams = @'
{
    "properties": {
        "schema": {
               "name": "{TableName}_CL",
               "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "dateTime"
                    }, 
                    {
                        "name": "Computer",
                        "type": "string"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "Time",
                        "type": "dateTime"
                    },
                    {
                        "name": "Code",
                        "type": "int"
                    },
                    {
                        "name": "Severity",
                        "type": "string"
                    },
                    {
                        "name": "Module",
                        "type": "string"
                    },
                    {
                        "name": "Message",
                        "type": "string"
                    }
              ]
        }
    }
}
'@

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

Преобразование

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

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

source | extend TimeGenerated = todatetime(Time) | project-away Time

Это приведет к выполнению следующего журнального запроса. Обратите внимание, что Time столбец пуст, а значение этого свойства используется для TimeGenerated.

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

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

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

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

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