6 日志文件监控

概述

Zabbix 可用于有/无日志轮询支持的日志文件的集中监控和分析。

当日志文件包含某些字符串或字符串模式时，可以使用通知来警告用户。

要监控日志文件，必须具有如下：

• 主机上已运行Zabbix agent
• 设置日志监控项

被监控日志文件的大小限制取决于大文件支持。

配置

验证代理参数

确保在 代理配置文件 中已设置：

• ‘Hostname’参数与前端的主机名一致
• ‘ServerActive’参数中的服务器被指定用于处理主动检查

监控项配置

配置一个日志 监控项

所有标有红色星号的为必填字段。

具体日志监控项的输入：

注意事项

• 服务器和代理将监视日志的大小和最后修改时间(对于logrt)的跟踪保存在两个计数器中. 此外:
  • 代理还在内部使用inode编号（在UNIX/GNU/Linux上）、文件索引（在Microsoft Windows上）和前512个日志文件字节的MD5的求和，以便在日志文件被截断和轮询时改进决策。
  • 在UNIX/GNU/Linux系统中，假定日志文件存储的文件系统是报告inode号，可以用来跟踪文件。
  • 在Microsoft Windows系统上，Zabbix agent确定日志文件所在的文件系统类型，并使用:
    • 在NTFS文件系统上64位文件索引。
    • 在ReFS文件系统上 (仅从Microsoft Windows Server 2012开始支持)128位文件ID。
    • 在文件索引发生变化(例如FAT32、exFAT)的文件系统中，当日志文件轮询导致多个日志文件在相同的最后修改时间内出现时，使用回退算法在不确定的条件下采取合理的方法。
  • inode号，文件索引和MD5总和由Zabbix代理在内部收集。 它们不传输到Zabbix服务器，并且在Zabbix代理停止时丢失。
  • 不要使用“touch”程序修改日志文件的最后修改时间，不要在以后恢复原始名称的情况下复制日志文件（这将更改文件inode号）。 在这两种情况下，文件将被视为不同的，将从头开始进行分析，这可能会导致重复的告警。
  • 如果logrt[] 监控项有几个匹配的日志文件，并且Zabbix agent跟随其中最新的日志文件，并删除了最近的日志文件会出现一条警告消息"there are no files matching "<regexp mask>" in "<directory>"。 Zabbix代理将忽略修改时间小于代理看到的logrt[] 被检查监控项的最近修改时间的日志文件。
• 代理从上次停止的点开始读取日志文件。
• 在代理刚刚启动或已收到以前被禁用或不支持的监控项的情况下，已经分析的字节数（大小计数器）和最后修改时间（时间计数器）存储在Zabbix数据库中并发送到代理，以确保代理从此开始读取日志文件。但是，如果代理从服务器接受非零大小的计数器, 而logrt[] 和 logrt.count[] 监控项没有找到，也没找到匹配的文件,若文件稍后出现，大小计数器将重置为0，将从头开始分析。
• 每当日志文件变得小于代理已知的日志大小计数器时，计数器将重置为零，代理从开始位置读取日志文件，将时间计数器考虑在内。
• 如果目录中存在多个匹配文件，且最后修改时间相同，则代理会尝试以相同的修改时间对所有日志文件进行正确分析，并避免跳过数据或分析相同的数据两次（尽管有时不能保证）。代理不承担任何特定的日志文件轮询方案。当提供具有相同修改时间的多个日志文件时，代理将以字典顺序降序处理它们。 因此，对于某些轮询方案，日志文件将按原始顺序进行分析。对于其它轮询方案，原始日志文件顺序将不会被执行，这可能导致以更改顺序报告匹配的日志文件记录（如果日志文件的上次修改时间不同，则不会发生问题）。
• Zabbix agent每 更新间隔 秒处理一次日志文件的新记录。
• Zabbix agent不会每秒发送超过日志文件的 最大值。 该限制可防止网络和CPU资源的过载，并会覆盖 代理配置文件中 MaxLinesPerSecond 参数提供的默认值。
• 要找到所需的字符串，Zabbix将处理比MaxLinesPerSecond中设置的多10倍的新行。例如，如果log[]或 logrt[]监控项的 更新间隔 为1秒，那么在默认情况下，代理将分析不超过200条日志文件记录，并在一次检查中向Zabbix server发送不超过20条的匹配记录。通过在代理配置文件中增加MaxLinesPerSecond，或在监控项键中设置 maxlines 参数，一次检查可将分析日志文件记录和发送到Zabbix服务器的1000条匹配记录增加到10000条。如果 更新间隔 设置为2秒，那么一次检查的限制将被设置为高于_更新间隔_1秒的2倍
• 此外，即使其中没有非日志值，日志和日志计数值始终限为代理发送缓冲区大小的50％。 因此，为了在一个连接（而不是几个连接）中发送maxlines值，代理的 缓冲区大小 参数必须至少为maxlines x 2。
• 在没有日志项的情况下，所有代理缓冲区大小都用于非日志值。当日志值出现时，它们会根据需要替换旧的非日志值，最多可替换为指定的50%.
• 对于大于256kB的日志文件记录，只有前256kB与正则表达式匹配，而其余部分将被忽略。但是，如果Zabbix agent在处理长记录时停止，则会丢失代理的内部状态，并且在重新启动代理之后，可以对长记录进行不同的分析。
• 特别注意“”路径分隔符: 如果file_format是”file.log”, 则不应该有“file”目录, 因为不可能明确地定义“.”是转义的还是文件名的第一个符号。
• 仅在文件名中支持logrt 的正则表达式，不支持目录正则表达式匹配。
• 在UNIX平台上，如果要找的日志文件的目录不存在，则logrt[]监控项将变为NOTSUPPORTED。
• 在Microsoft Windows上，如果目录不存在，则监控项将不会变为NOTSUPPORTED（例如，目录在监控项键中拼写错误）。
• 没有用于logrt[]监控项的日志文件不会使其NOTSUPPORTED。读取logrt[]监控项的日志文件的错误将作为告警记录到Zabbix agent日志文件中，但不会使监控项变成NOTSUPPORTED。
• Zabbix agent日志文件可以帮助你找出为什么log[]或logrt[] 监控项会成为NOTSUPPORTED。Zabbix可以监视其代理日志文件，除了在DebugLevel=4时。

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

有时我们可能只想从目标文件中提取感兴趣的值，而不是在找到正则表达式匹配时返回整行。

自Zabbix2.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

Zabbix只返回数字的原因是因为\1 定义的，指的是第一个也是唯一的想要的子组：([0-9]+)

而且，通过提取和返回数字的能力，该值可用于定义触发器。

使用maxdelay参数

日志监控项中的“maxdelay”参数允许忽略日志文件中的一些较旧的行，以便在“maxdelay”秒内获取最近分析的行。

指定’maxdelay’>0可能导致忽略重要的日志文件记录和错过的报警，只有在必要时才使用否则后果自负。

默认情况下，日志监控项将跟踪出现在日志文件中的所有新行。 但是，有些应用程序在某些情况下开始在其日志文件中写入大量的消息。例如，如果数据库或DNS服务器不可用，则此类应用程序会向日志文件中注入数千条几乎相同错误消息，直到恢复正常为止。默认情况下，所有这些消息将被完全分析，并将匹配的行发送到配置为log 和logrt监控项的服务器上。

内置的过载保护包括一个可配置的“maxlines”参数（保护服务器免受过多传入匹配日志行的影响）和 10*“maxlines”限制（保护主机 CPU 和 I/O 免于agent在一次检查中过载） . 尽管如此，内置保护仍存在两个问题。 首先，大量可能不那么有用的消息被报告给服务器并占用数据库空间。 其次，由于每秒分析的行数有限，agent可能会落后于最新的日志记录数小时。 很可能，您可能更愿意尽快了解日志文件中的当前情况，而不是花几个小时在旧记录中爬行。

这两个问题的解决方案是使用“maxdelay”参数。 如果指定 ‘maxdelay’ > 0，则在每次检查处理的字节数时，测量剩余字节数和处理时间。 agent根据这些数字计算估计的延迟——分析日志文件中所有剩余记录需要多少秒。

如果延迟不超过“maxdelay”，那么agent将像往常一样继续分析日志文件。

如果延迟大于“maxdelay”，那么agent将通过“跳转”到一个新的估计位置来忽略日志文件的一个块，以便在“maxdelay”秒内分析剩下的行。

请注意，agent甚至不会将忽略的行读入缓冲区，而是计算要在文件中跳转的大致位置。

跳过日志文件行的事实记录在代理日志文件中，如下所示：

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”数字是近似的，因为在“跳转”之后，agent将文件中的位置调整到日志行开头，日志行可能在文件中更远或更早。

根据增长速度与分析日志文件的速度的不同，你可能会看到没有”跳转”、少有或经常”跳转”、大或小的”跳转”，甚至每次检查中的”跳转”都很小。系统负载和网络延迟的波动也会影响延迟的计算，因此”跳转”可以跟上“maxdelay”参数。

不推荐设置 ‘maxdelay’ <’update interval’（这可能会导致频繁的”jumps”）

处理“copytruncate”日志文件轮换的注意事项

带有copytruncate 选项的logrt假定不同的日志文件有不同的记录(至少它们的时间戳不同)，因此初始块的MD5(最多512字节)将不同。两个具有相同的MD5初始块和的文件意味着其中一个是原始块，另一个是副本。

使用copytruncate选项的logrt将努力正确处理日志文件副本，而不报告副本。但是，与logrt[]监控项更新间隔相比，生成具有相同时间戳的多个日志文件副本、日志文件轮询频率更高、不建议频繁重新启动代理。代理试图合理地处理所有这些情况，但是在所有情况下都不能保证良好的结果。

关于持久文件的 log*[] 监控项的注释

I/O负载

每一批数据 (包含项目的数据)成功发送到服务器后，项目的持久文件就会更新， 例如, 默认的 ‘BufferSize’是100。如果一个日志项找到 70 条匹配记录， 那么前 50 条记录将分批发送，持久化文件将被更新，然后剩余 20 条记录将被发送(可能会有一些延迟，更多数据积累) 在第二批中，并且将再次更新持久文件。

代理和服务器之间通信失败时的操作

来自log[]和logrt[]监控项的每个匹配行以及每个log.count[] 和 logrt.count[]监控项检查的结果都需要代理发送缓冲区中指定的50％区域中的空闲时隙。缓冲区元素定期发送到服务器（或代理服务器），缓冲区可以再次释放。

虽然代理发送缓冲区中的指定日志区域中有空闲时隙，并且代理和服务器（或代理服务器）之间的通信失败，但是日志监控结果在发送缓冲区中累积。这有助于缓解短暂的通信故障。

在较长的通信失败期间，所有日志槽都被占用，并采取以下操作：

• log[]和logrt[]监控项检查已停止。当通信恢复并且缓冲器中的空闲插槽可用时，从先前的位置恢复检查。若没有匹配的行丢失，稍后再报告.
• 如果maxdelay = 0（默认），则log.count[]和logrt.count[]监控被停止。 这种行为类似于上述的log[] 和logrt[]监控项。 请注意，这可能会影响log.count[]]和logrt.count[]结果：例如，一次检查计算出日志文件中有100个匹配行，但是由于缓冲区中没有空闲插槽，因此停止检查。 当通信恢复时，代理将计数相同的100条匹配行，还有70条新的匹配行。代理会发送count=170，就像它们在一次检查中发现的一样。
• log.count[] 和logrt.count[]]检查与maxdelay > 0：如果在检查期间没有“跳转”，则行为类似于上述。 如果在日志文件行上发生“跳转”，则保留“跳转”之后的位置，同时计算结果被丢弃。 因此，即使在通信失败的情况下，代理也试图跟上日志文件的增长速度。

持久文件的目的

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

正在运行的代理维护大的属性集，用于在检查之间跟踪所有受监视的日志文件。当代理停止时，这种内存状态会丢失。

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

主要的用户场景是监控位于镜像文件系统中的日志文件，直到某个时刻，日志文件被写入两个镜像。然后镜像被分割。在活动副本上，日志文件仍在增长，获取新记录。Zabbix agent 对其进行分析并将处理后的日志大小和修改时间发送到服务端。在被动副本上，日志文件保持不变，远远落后于活动副本。稍后操作系统和 Zabbix agent从被动副本重新启动。Zabbix agent从服务器接收到的已处理日志大小和修改时间可能对被动副本的情况无效。要从文件系统镜像拆分时代理停止的位置继续进行日志文件监控，代理会从持久文件恢复其状态。

持久文件的代理操作

在启动时 Zabbix agent 对持久文件一无所知。只有在收到来自 Zabbix server (proxy)的活动检查列表后，代理才会看到某些日志项应该由指定目录下的持久文件支持。

在代理操作期间，持久文件被打开以进行写入（使用 fopen(filename, “w”)）并用最新数据覆盖。如果同时发生覆盖和文件系统镜像拆分，丢失持久文件数据的机会非常小，无需特殊处理。写入持久文件后不会强制同步到存储介质（不调用 (fsync())。

在成功向 Zabbix server报告匹配的日志文件记录或元数据(处理的日志大小和修改时间)后，使用最新数据覆盖。这可能与每个监控项检查日志文件是否不断变化一样频繁。

代理关闭期间没有特殊操作。

在收到活动检查列表后，代理会将过时的持久文件标记为删除。如果出现以下情况，则持久文件将过时：1) 不再监视相应的日志项，2) 使用与以前不同的persistent_dir位置重新配置日志项

删除会延迟 24 小时完成，因为处于 NOTSUPPORTED 状态的日志文件不包含在活动检查列表中，但它们可能会在稍后变为 SUPPORTED，并且它们的持久文件将很有用。

如果代理在 24 小时到期之前停止，则不会删除过时的文件，因为 Zabbix agent不再从 Zabbix server获取有关其位置的信息。

在代理停止时，将日志项 persistent_dir 重新配置回旧的 persistent_dir 位置，用户没有删除就的持久文件 - 将导致从旧的持久化文件中恢复代理状态，从而导致丢失消息或错误告警。

持久文件的命名和位置

Zabbix agent 通过他们的键来区分活动检查。例如：logrt[/home/zabbix/test.log] 和 logrt[/home/zabbix/test.log,] 是不同的监控项。将前端的项logrt[/home/zabbix/test.log,,,10]修改为 logrt[/home/zabbix/test.log,,,20] 会导致 logrt[/home/zabbix/test.log,,,10]项从代理的活动检查清单中删除并创建logrt[/home/zabbix/test.log,,,20] 监控项 (某些属性在前端/服务器中进行修改，而不是在代理中)。

文件名由监控项密钥的 MD5 和加上监控项密钥长度组成，以减少冲突的可能性。例如， logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] 监控项的状态将保存在持久文件c963ade4008054813bbc0a650bb8e09266中。

多个日志项可以使用相同的值 persistent_dir。

persistent_dir 是通过考虑特定文件系统布局、挂载点和挂载选项以及存储镜像配置来指定的 - 持久文件应该与受监控的日志文件位于同一镜像文件系统上。

如果 persistent_dir 目录无法创建或不存在，或者Zabbix agent 的访问权限不允许创建/写入/读取/删除文件，则日志项将变为 NOTSUPPORTED。

如果在代理操作期间删除了对持久存储文件的访问权限或发生其他错误（例如磁盘已满），则错误将记录到代理日志文件中，但日志项不会变为 NOTSUPPORTED。