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

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

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

注释

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

先决条件

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

配置自定义文本文件数据源

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

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

设置	DESCRIPTION
文件模式	标识本地磁盘上日志文件的位置和名称。对不同的文件名使用通配符，例如每天用新名称创建新文件时。可以输入以逗号分隔的多个文件模式。只能在文件名和文件名上方的第一级文件夹名称中使用通配符。例子： - C:\Logs\MyLog.txt - C：\Logs\MyLog.txt -C：\Logs\IIS\.logs - C:\App01\AppLog.txt，C:\App02\AppLog.txt - /var/mylog.log - /var/mylog.log - /var/logs//
表名称	Log Analytics 工作区中目标表的名称。此表必须已存在。
记录分隔符	指示日志条目之间的分隔符。 `TimeStamp` 是唯一允许的当前值。这会查找指定格式 `timeFormat` 的日期，以标识新记录的开始。如果未找到指定格式的日期，则使用行尾。有关更多详细信息，请参阅时间格式。
TimeStamp 格式	日志文件中使用的时间格式，如以下时间格式中所述。
转换	引入时转换，用于筛选记录或设置目标表的传入数据的格式。用于 `source` 使传入的数据保持不变，并发送到 `RawData` 列。有关使用转换的示例，请参阅带分隔符的日志文件。

添加目标

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

时间格式

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

时间格式	示例：
`ISO 8601` ¹	2024-10-29T18：28：34Z
`yyyy-MM-ddTHH:mm:ssk`	2024-10-29T18：28：34Z 2024-10-29T18：28：34+01：11
`YYYY-MM-DD HH:MM:SS`	2024-10-29 18:28:34
`M/D/YYYY HH:MM:SS AM/PM`	2024年10月29日 18：28：34
`Mon DD, YYYY HH:MM:SS`	2024年10月29日 18：28：34
`yyMMdd HH:mm:ss`	241029 18:28:34
`ddMMyy HH:mm:ss`	291024 18:28:34
`MMM d HH:mm:ss`	10 月 29 日 18：28：34
`dd/MMM/yyyy:HH:mm:ss zzz`	2024/10/14 18:28:34 -00

¹ 不支持带有小数部分/亚秒级精度的 ISO 8601 时间戳。

文本文件要求和最佳做法

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 工作区中的指定表。 Log Analytics 工作区中接收数据的自定义表必须存在，然后才能创建 DCR。

下表描述了工作区表中的必需列和可选列。表可以包含其他列，但除非使用带分隔符的日志文件中所述的转换分析数据，否则这些列不会填充值。

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

¹ 如果使用转换将数据分析为多个列，则表不必包含 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。

重要

在将此转换添加到 DCR 之前，必须将这些列添加到目标表。可以修改上述 PowerShell 脚本，以在创建表时包含其他列。或使用 Azure 门户，如 “添加或删除自定义列 ”中所述，将列添加到现有表。

转换查询的主要细节包括：

查询输出的每个属性字段均与目标表中的列名称相匹配。
此示例重命名 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 代理程序。
详细了解数据收集规则。

Last updated on 2026-03-25