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

虚拟机上的许多应用程序和服务会将信息记录到文本文件中，而不是 Windows 事件日志或 Syslog 等标准日志记录服务。 可以使用带有自定义文本日志数据源的数据收集规则（DCR）从虚拟机收集自定义文本日志。

有关创建 DCR 的详细信息，请参阅 使用 Azure Monitor 从 VM 客户端收集数据。 本文提供了自定义文本日志数据源类型的其他详细信息。

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

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

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

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

下表描述了 DCR 设置中 timeFormat 支持的时间格式。 如果日志条目中包含具有指定格式的时间，则它将用于标识新的日志条目。 如果未找到指定格式的日期，则行尾用作分隔符。 有关此设置的使用方式的进一步说明，请参阅 多行日志文件 。

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

日志文件中的每个条目都是在创建日志文件时收集的，并将其发送到 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.

如果在 DCR 中使用时间戳格式 YYYY-MM-DD HH:MM:SS ，则会以与上一示例相同的方式收集数据。 额外行将包含在 RawData 列中。 如果使用了与日志条目中的日期不匹配的另一个时间戳格式，则会将每个条目收集为两个单独的记录。

许多文本日志文件具有以逗号等字符分隔的列的条目。 与其将整个条目发送到 RawData 列，你可以将数据解析为独立的列，以便每一列都可以填充到目标表中。 使用包含拆分函数的转换执行此分析。

上面显示的示例文本文件以逗号分隔，字段可以描述为：Time、、Code、Severity和ModuleMessage。 若要将此数据分析为单独的列，请将每个列添加到目标表，并将以下转换添加到 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 代理程序。
• 详细了解数据收集规则。