6 日志文件监控

概述

Zabbix可用于集中监控和分析日志文件 支持/不支持日志轮转功能

当日志file包含特定字符串或string模式时 可通过通知功能向用户发出告警

监控日志file需要满足以下条件:

• 在主机上运行的Zabbix agent
• 已配置日志监控监控项

配置

验证 agent 参数

确保在agent configuration file中:

• 'Hostname'参数需与前端中的主机名称匹配
• 'ServerActive'参数中指定的服务器用于处理主动检查

监控项配置

配置日志监控概述.

所有必填字段均以红色星号标记.

针对日志监控监控项需填写以下内容:

重要说明

• server 和 agent 会记录被监控日志文件的大小变化轨迹 最后修改时间（针对logrt）以两个计数器形式记录。此外：
  • agent 内部也使用 inode 编号（在 UNIX/GNU/Linux), file 索引（在 Microsoft Windows 上）和 MD5 前512个日志file字节的总和，用于改进决策 当日志文件get被截断并轮转时。
  • 在UNIX/GNU/Linux系统上，假定file系统 日志文件存储位置报告inode编号，该编号可以 用于跟踪文件。
  • 在Microsoft Windows上，Zabbix agent决定了file系统 日志文件所在的类型并使用：
    • 在NTFS file系统上使用64位 file索引。
    • 在ReFS file系统上（仅限Microsoft Windows Windows Server 2012) 128位file标识符。
    • 在file系统上，当file索引发生变化时（例如FAT32， exFAT) 将使用回退算法来采取合理的 在日志file轮换的不确定条件下的方法 导致多个日志文件具有相同的最后 修改时间。
  • inode编号、file索引和MD5校验和在内部 由Zabbix agent收集。它们不会被传输到Zabbix 服务器并在Zabbix agent停止时丢失。
  • 不要修改日志文件的最后修改时间 'touch'工具，不要copy日志file并进行后续恢复 原始名称的（这将更改file inode编号）。 在这两种情况下，file 将被视为不同的并且会 从开始分析，可能导致重复警报。
  • 如果存在多个匹配的日志文件用于logrt[] 监控项 且 Zabbix agent 遵循其中最新的规范 最近日志file已被删除，一条警告消息 "there are no files matching "<regexp mask>" in "<directory>" 已记录。Zabbix agent 忽略修改时间的日志文件 早于agent记录的最新修改时间 对于正在检查的logrt[] 监控项
• agent开始从上次停止的位置继续读取日志file 之前的时间
• 已分析的字节数（大小计数器）及最后 修改时间（时间计数器）存储在Zabbix中 数据库并被发送到agent以确保agent启动 从这一点开始读取日志file，在agent仅为的情况下 已启动或已接收到之前禁用或未启用的监控项 支持。然而，如果agent接收到非零大小 来自服务器的计数器，但logrt[]或logrt.count[] 监控项是 无法找到匹配的文件，大小计数器为 如果文件稍后出现，则重置为0以从头开始分析。
• 每当日志file变得小于日志大小计数器时 由agent所知，计数器被重置为零且agent 从日志file的开头开始读取时间 计数器考虑在内。
• 如果有多个匹配文件具有相同的最后修改时间 目录中的时间，然后agent尝试正确分析所有 具有相同修改时间的日志文件，避免跳过数据或 对相同数据进行重复分析，尽管无法完全保证 所有情况下。agent不假定任何特定的日志file 轮换方案也未确定一个。当呈现多个日志时 具有相同最后修改时间的文件，agent将处理 将它们按字典序降序排列。因此，对于某些 日志文件将按照轮换方案进行分析和报告 它们的原始顺序。对于其他轮转方案，原始日志 file 顺序将不被遵循，这可能导致报告匹配 日志 file 记录顺序异常（若...则不会出现此问题 日志文件的最后修改时间不同).
• Zabbix agent 每次 更新 时处理日志 file 的新记录 interval 秒。
• Zabbix agent 每次不会发送超过 maxlines 行日志 file second. 该限制可防止网络和CPU资源过载 并覆盖由MaxLinesPerSecond提供的默认值 agent configuration file中的参数
• 为了找到所需的string，Zabbix将处理10倍以上的新数据 每秒钟输出的行数超过MaxLinesPerSecond设置的值。例如，如果log[] 或 logrt[] 监控项 默认具有1秒的更新间隔 agent 最多分析200条日志file记录并将发送 每次检查中不超过20条匹配记录到Zabbix server。 增加MaxLinesPerSecond在agent配置file中或 在监控项键中设置maxlines参数，可以限制 增加到10000条已分析日志file记录和1000条匹配 在一次检查中发送到Zabbix server的记录数。如果更新间隔 设置为2秒时，单次检查的限制将被设定为2倍 高于更新间隔为1秒的情况。
• 此外，log和log.count的值始终限制在50%以内 agent发送缓冲区大小，即使其中不包含非日志值 因此，为了在一次连接中发送maxlines值（且 不在多个连接中), agent BufferSize 参数必须 至少为maxlines x 2。Zabbix agent可以在日志收集期间上传数据从而释放缓冲区，而Zabbix agent 2会停止日志收集直到数据上传完成且缓冲区被释放，这一过程是异步执行的。
• 当缺少日志监控项时，所有agent缓冲区大小将被使用 非日志值。当接收到日志值时，它们会替换较旧的 根据需要记录非日志值，最多可达指定的50%。
• 对于超过256kB的日志file记录，仅保留前256kB内容 与正则表达式匹配后，记录的其余部分是 被忽略。然而，如果Zabbix agent在处理过程中被停止 拥有长记录时，agent内部状态会丢失且长 记录可能会在agent之后被再次且以不同方式分析 重新启动。
• 关于"\"路径分隔符的特殊说明：如果file_format是 file\.log"，那么就不应该存在file目录，因为 无法明确界定"."是否被转义 file名称的首个字符。
• logrt 支持在文件名中使用正则表达式, 不支持目录正则表达式匹配。
• 在UNIX平台上，当logrt[] 监控项变为NOTSUPPORTED时 日志文件预期所在的目录未找到 存在。
• 在Microsoft Windows上，如果目录不存在，监控项将 不会变为NOTSUPPORTED（例如，如果目录名称拼写错误） 监控项 键).
• logrt[] 监控项缺少日志文件并不会使其失效 不支持. 读取logrt[]监控项日志文件时发生的错误 记录为警告到Zabbix agent日志file但不会使 监控项 不支持。
• Zabbix agent 日志 file 有助于查明为何 log[] 或 logrt[] 监控项 变为NOTSUPPORTED状态。Zabbix可以监控其agent日志 file，除非处于DebugLevel=4或DebugLevel=5级别时除外。
• 使用正则表达式搜索问号时，例如\?，如果文本file包含NUL符号，可能会导致误报，因为这些符号会被Zabbix替换为"?"以继续处理该行直到换行符。

提取正则表达式的匹配部分

有时我们可能希望仅从目标file中提取感兴趣的值 而不是在正则表达式匹配时返回整行内容

自Zabbix 2.2.0起，日志监控项具备从匹配行中提取所需值的能力 这是通过在log和logrt 监控项中 添加output参数实现的

使用'output'参数可以指定我们感兴趣的匹配"捕获组"

例如

log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

将允许返回在以下内容中找到的条目计数：

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
       buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
       ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

由于\1引用第一个且唯一的捕获组：([0-9]+) 所以仅返回数字

通过提取并返回数字的能力 该值可用于定义触发器

使用 maxdelay 参数

log 监控项中的'maxdelay'参数允许忽略部分较旧的行 从日志文件中以get最近分析的行 'maxdelay' 秒。

默认情况下，日志监控的监控项会追踪文件中出现的所有新行 日志文件。然而，某些应用程序在某些情况下 开始在其日志文件中写入大量消息。 例如，如果数据库或DNS服务器不可用，此类应用程序 日志文件被数千条几乎相同的错误消息淹没直至 恢复正常运行。默认情况下，所有这些消息都将 经过分析并匹配的行按配置发送至服务器 log 和 logrt 监控项。

内置过载保护机制包含可配置的 'maxlines' 参数（防止服务器接收过多匹配的输入数据） 日志行数）以及10倍'maxlines'的限制（保护主机的CPU和I/O免受 在一个检查中通过agent进行重载）。然而，仍然存在2个问题： 内置保护。首先，大量潜在的 非信息性消息被报告至服务器并占用存储空间 数据库。其次，由于每次分析的行数有限 其次，agent 可能会滞后于最新日志记录数小时。相当 您可能更希望尽快了解当前情况 日志文件中的情况，而非费力翻阅旧记录 小时

解决这两个问题的方案是使用'maxdelay'参数。如果 如果指定了'maxdelay' > 0，则在每次检查期间会计算 已处理的字节数、剩余字节数及处理时间 根据这些数值，agent会计算出一个预估延迟 分析日志中所有剩余记录需要多少秒 file

如果延迟未超过'maxdelay'，则agent继续执行 照常分析日志file。

如果延迟大于'maxdelay'，则agent 忽略一个数据块 通过"跳过"日志file来跳转到一个新的预估位置 剩余行可在'maxdelay'秒内完成分析。

请注意，agent甚至不会将忽略的行读入缓冲区 在file中计算一个近似跳跃位置

跳过日志file行的事实会被记录在agent日志file中 这个

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
       logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
       (from byte 75653115 to byte 76332973) to meet maxdelay

"to byte"数值为近似值，因为在"jump"之后agent 将file中的位置调整到日志行的开头 可能在file之后或之前。

根据增长速度与速度的比较情况 分析日志file时，您可能会发现没有"跳跃"、偶尔或频繁出现"跳跃" 大或小的"跳跃"，甚至每次检查中的小"跳跃"。 系统负载波动和网络延迟也会影响 延迟的计算，从而“跳跃”前进以跟上进度 "maxdelay"参数。

不建议将'maxdelay'设置为小于'update间隔'（这可能导致 导致频繁的小幅度"跳跃"。

关于处理'copytruncate'日志文件轮转的注意事项

带有copytruncate选项的logrt假定不同日志文件包含不同记录（至少时间戳不同），因此初始块（前512字节）的MD5校验和会不同。两个文件若初始块MD5校验和相同，则意味着其中一个是原始文件，另一个是copy。

带有copytruncate选项的logrt会正确处理日志file副本而不报告重复项。但需避免以下情况：生成具有相同时间戳的多个日志file副本、日志file轮转频率高于logrt[] 监控项 update间隔、频繁重启agent。agent会合理处理这些情况，但无法保证所有场景下都能获得理想结果。

日志持久化文件注意事项*[] 监控项

持久化文件的用途

当Zabbix agent启动时，它会从Zabbix server 或 proxy接收活动检查列表。对于log*[]指标，它会接收已处理的日志大小和修改时间，以确定从何处开始日志file监控。根据file系统报告的实际日志file大小和修改时间，agent决定是继续从已处理的日志大小处进行日志file监控，还是从头重新分析日志file。

运行中的agent会维护一组更大的属性，用于在检查之间跟踪所有受监控的日志文件。当agent停止时，这种memory内部状态会丢失。

新的可选参数persistent_dir指定了一个目录，用于存储log[]、log.count[]、logrt[]或logrt.count[] 监控项在file中的状态。在Zabbix agent重启后，日志监控项的状态会从持久化file中恢复。

主要使用场景是监控位于镜像file系统上的日志file。在某个时间点之前，日志file会同时写入两个镜像。然后镜像被拆分。在活跃的copy上，日志file仍在增长，不断添加新记录。Zabbix agent分析它并将已处理的日志大小和修改时间发送到服务器。在被动copy上，日志file保持不变，远远落后于活跃copy。之后，操作系统和Zabbix agent会从被动copy重新启动。Zabbix agent从服务器接收的已处理日志大小和修改时间可能对被动copy的情况无效。为了从file系统镜像拆分时agent停止的位置继续日志file监控，agent会从持久化file恢复其状态。

Agent 持久化文件操作

启动时 Zabbix agent 对持久化文件一无所知。只有在从 Zabbix server（proxy）接收到活动检查列表后，agent 才会发现某些日志 监控项 应由指定目录下的持久化文件支持。

在 agent 运行期间，持久化文件会以写入模式打开（使用 fopen(filename, "w")）并用最新数据覆盖。如果在覆盖操作和 file 系统镜像分裂同时发生，导致持久化 file 数据丢失的概率非常小，因此未做特殊处理。写入持久化 file 后不会强制同步到存储介质（未调用 fsync()）。

在成功向 Zabbix server 报告匹配的日志 file 记录或元数据（处理的日志大小和修改时间）后，会用最新数据覆盖。如果日志 file 持续变化，这种情况可能每 监控项 检查周期就会发生一次。

agent 关闭时不执行特殊操作。

在接收到活动检查列表后，agent会标记过时的持久化文件以便删除。一个持久化file在以下情况下会变为过时：1) 对应的日志监控项不再被监控，2) 日志监控项被重新配置为与之前不同的persistent_dir位置。

删除操作会延迟24小时执行，因为处于NOTSUPPORTED状态的日志文件不会包含在活动检查列表中，但它们可能稍后变为SUPPORTED状态，此时它们的持久化文件将派上用场。

如果agent在24小时到期前停止，那么过时文件将不会被删除，因为Zabbix agent无法再从Zabbix server获取这些文件的位置信息。

持久化文件的命名与存储位置

Zabbix agent 通过键值区分主动检查. 例如, logrt[/home/zabbix/test.log] 和 logrt[/home/zabbix/test.log,] 是 不同的 监控项. 在前端将 监控项 logrt[/home/zabbix/test.log,,,10] 修改为 logrt[/home/zabbix/test.log,,,20] 会导致从 agent 的主动检查列表中 删除 监控项 logrt[/home/zabbix/test.log,,,10] 并创建 logrt[/home/zabbix/test.log,,,20] 监控项 (某些属性会在前端/服务器修改时保留, 但不会在 agent 中保留).

file 名称由 监控项 键的 MD5 哈希值加上 监控项 键长度组成, 以减少冲突可能性. 例如, logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] 监控项 的状态将保存在持久性 file c963ade4008054813bbc0a650bb8e09266 中.

多个日志 监控项 可以使用相同的 persistent_dir 值.

persistent_dir 的指定需要考虑特定的 file 系统布局、 挂载点和挂载选项以及存储镜像配置 - 持久性 file 应与被监控的日志 file 位于同一镜像文件系统上.

如果无法创建 persistent_dir 目录或该目录不存在, 或者 Zabbix agent 的访问权限不允许 create/写入/读取/delete 文件, 则日志 监控项 将变为 NOTSUPPORTED.

如果在agent操作期间移除了持久存储文件的访问权限 或发生其他错误（例如磁盘已满），则错误会被记录到agent日志 file中，但日志监控项不会变为NOTSUPPORTED状态。

I/O 负载

监控项的持久化file会在每批数据（包含监控项的数据）成功发送至服务器后更新。例如，默认的'BufferSize'为100。如果某个日志监控项匹配到70条记录，前50条记录会作为第一批发送，持久化file随即更新；剩余的20条记录将在第二批发送（可能会延迟以积累更多数据），之后持久化file会再次更新。

当 agent 与服务器通信失败时的操作

来自log[]和logrt[]的每个匹配行监控项以及每个结果 log.count[] 和 logrt.count[] 监控项 检查需要一个空闲插槽 在agent发送缓冲区中指定了50%的区域。缓冲区元素是 定期发送到服务器（或proxy），缓冲区槽位再次释放。

当agent发送缓冲区中有空闲槽位时 agent与服务器（或proxy）之间的缓冲区和通信故障 日志监控结果会累积在发送缓冲区中。这有助于 缓解短暂的通信故障。

在长时间通信故障期间，所有日志槽位get被占满且 采取以下操作：

• log[] 和 logrt[] 监控项 检查已停止。当通信 缓冲区中的已恢复和空闲槽位可用时，检查将 从先前位置恢复。不会丢失任何匹配行，它们 稍后才会报告。
• log.count[] 和 logrt.count[] 检查会在以下情况停止 maxdelay = 0（默认）。行为类似于log[]和 logrt[] 监控项 如上所述。请注意这可能会影响 log.count[] 和 logrt.count[] 结果：例如，一次检查 在日志中统计100条匹配行file，但由于没有可用的 缓冲区中的槽位检查停止。当通信时 恢复了agent计数相同的100条匹配行以及70条 新匹配的行。agent现在发送count = 170，就好像它们是 在一次检查中发现。
• log.count[] 和 logrt.count[] 检查与 maxdelay > 0：如果 检查期间没有出现"跳跃"，则行为类似于 上述描述。如果发生了跳过日志file行的情况，则 "jump"后的位置被保留，计数结果被丢弃。 因此，agent会持续追踪不断增长的日志file，即使出现异常情况 通信故障

正则表达式编译与运行时错误的处理

如果在log[]、logrt[]、log.count[]或logrt.count[]监控项中使用的正则表达式无法被PCRE或PCRE2库编译，则该监控项会进入NOTSUPPORTED状态并显示错误消息。要继续监控日志监控项，应修复正则表达式。

如果正则表达式编译成功，但在运行时失败（在某些或所有日志记录上），则日志监控项仍保持支持状态并继续监控。运行时错误会被记录在Zabbix agent日志file中（不包含日志file记录）。

请注意，正则表达式运行时错误的记录功能自Zabbix 6.0.21起支持。

记录速率限制为每次检查一个运行时错误，以便Zabbix agent可以监控其自身的日志file。例如，如果分析了10条记录，其中3条记录因正则表达式运行时错误而失败，则会在agent日志中生成一条记录。

例外情况：如果MaxLinesPerSecond=1且update间隔=1（每次检查仅允许分析1条记录），则不会记录正则表达式运行时错误。

zabbix_agentd会在运行时错误时记录监控项键，zabbix_agent2则会记录监控项 ID以帮助识别哪个日志监控项存在运行时错误。建议在出现运行时错误时重新设计正则表达式。