使用 Azure Monitor 从虚拟机收集 JSON 文件

發行項
2025/04/30

许多应用程序和服务将信息记录到文本文件，而不是标准日志记录服务（例如 Windows 事件日志或 Syslog）。如果此数据以 JSON 格式存储，Azure Monitor 可以使用自定义 JSON 日志数据源在数据收集规则（DCR）中收集这些数据。

使用 Azure Monitor 代理收集数据中提供了有关创建 DCR 的详细信息。本文提供有关 JSON 日志类型的其他详细信息。

注意

若要直接使用 DCR 定义或使用 ARM 模板等其他方法进行部署，请参阅 Azure Monitor 中的数据收集规则（DCR）示例。

先决条件

除了使用 Azure Monitor 从虚拟机客户端收集数据中列出的先决条件之外，还需要 Log Analytics 工作区中的自定义表来接收数据。有关此表的要求的详细信息，请参阅 Log Analytics 工作区表。

配置自定义 JSON 文件数据源

通过使用 Azure Monitor 从虚拟机客户端收集数据中的流程创建 DCR。在 DCR 的“收集和传递”选项卡上，从“数据源类型”下拉列表中选择“自定义 JSON 日志”。

下表介绍了 自定义 JSON 日志 配置中提供的选项。

设置	DESCRIPTION
文件模式	标识本地磁盘上日志文件的位置和名称。对不同的文件名使用通配符，例如每天用新名称创建新文件时。可以输入以逗号分隔的多个文件模式。例子： - C:\Logs\MyLog.txt - C:\Logs\MyLog.txt - C:\App01\AppLog.txt，C:\App02\AppLog.txt - /var/mylog.log - /var/mylog.log
表名称	Log Analytics 工作区中目标表的名称。
转换	引入时转换以筛选记录或设置目标表的传入数据的格式。使用 `source` 使传入的数据保持不变。有关示例，请参阅转换。
JSON 架构	要从 JSON 日志文件中收集并发送到目标表的属性。唯一必需的属性是 `TimeGenerated`。如果 JSON 文件未提供此值，将使用引入时间。 Log Analytics 工作区表中描述的非必需的其他列也可以包含，并且会自动填充。任何其他属性将填充表中与其同名的列。确保与表列匹配的属性使用与相应列相同的数据类型。上图显示了 JSON 文件要求和最佳做法中显示的示例 JSON 文件的 JSON 架构

添加目标

自定义 JSON 日志只能发送到 Log Analytics 工作区，该工作区存储在创建的自定义表中。添加 Azure Monitor 日志 类型的目标并选择 Log Analytics 工作区。只能将单个工作区添加到自定义 JSON 日志数据源的 DCR。如果需要多个目标，请创建多个 DCR。请注意，这会向每个接收方发送重复数据，这样会导致额外的费用。

JSON 文件要求和最佳做法

Azure Monitor 代理正在收集的文件必须满足以下要求：

该文件必须存储在受监视的目录中代理计算机的本地驱动器上。
每个条目必须包含在一行中，并以行尾分隔。不支持 JSON 正文格式。请查看以下示例。
文件必须使用 ASCII 或 UTF-8 编码。不支持其他格式，如 UTF-16。
新记录应附加到文件末尾，而不是覆盖旧记录。覆盖将导致数据丢失。

下面是 Azure Monitor 可以收集的典型 JSON 日志文件的示例。这包括字段：Time、、CodeSeverity、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 个以上的目录。查询过多的目录会导致性能下降。
持续清理受监视目录中的日志文件。跟踪过多日志文件可能会提高代理 CPU 和内存使用率。请至少等待 2 天，以便有足够的时间处理所有日志。
请勿将与文件扫描模式匹配的文件重命名为同样与文件扫描模式匹配的其他名称。这将导致重复数据被摄入。
请勿重命名与文件扫描模式匹配的大型日志文件或将其复制到受监视的目录。如果必须这样做，则每分钟不得超过 50MB。

Log Analytics 工作区表

代理监视本地磁盘上与指定名称模式匹配的任何 json 文件。每当条目写入日志后，会立即收集并解析，然后发送到 Log Analytics 工作区中指定的表中。 Log Analytics 工作区中接收数据的自定义表必须存在，然后才能创建 DCR。

表中与已分析 Json 数据中的字段名称匹配的任何列都将用日志条目中的值填充。下表介绍了工作区表中的必需列和可选列，这些列是对您 JSON 数据中标识的列的补充。

列	类型	必需？	DESCRIPTION
`TimeGenerated`	日期/时间	是的	此列包含生成记录的时间，并且在所有表中是必需的。该值将根据记录添加到 Log Analytics 工作区的时间自动填充。可以使用转换来覆盖此值，以便将`TimeGenerated`设置为日志条目中的某个值。
`Computer`	字符串	否	如果表包含此列，则会使用从中收集日志条目的计算机的名称填充该列。
`FilePath`	字符串	否	如果表包含此列，则会使用从中收集日志项的日志文件的路径填充该表。

下面的示例演示了一个查询，该查询从为上面所示的示例 JSON 文件创建的表中返回数据。它使用上面所示的示例 JSON 架构，通过 DCR 收集。由于 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 的默认转换。否则，请使用 KQL 查询返回所需架构的方式，修改 ARM 模板的 transformKql 部分。

例如，在上面的示例中，日志条目具有一个 Time 字段，其中包含创建日志条目的时间。与其将此列作为单独的 Time 列存储到目标表中，不如使用以下转换将 TimeGenerated 属性的值映射到 Time。

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

这将导致以下日志查询。请注意，该 Time 列为空，该属性的值用于 TimeGenerated。

故障排除

如果没有从预期的 JSON 日志中收集到数据，请执行以下步骤。

验证数据是否正在写入到所收集的日志文件。
验证日志文件的名称和位置是否与指定的文件模式匹配。
验证 DCR 中传入流的架构是否与日志文件中的架构匹配。
验证目标表的架构是否与传入流匹配，或者你是否具有将传入流转换为正确架构的转换。
请参阅验证操作，检查代理是否正在运行和是否正在接收数据。

后续步骤

详细了解 Azure Monitor 代理。
详细了解数据收集规则。

共用方式為