Zabbix 可用于集中监控和分析日志文件,支持或不支持日志轮转。
当某个日志 file 包含特定字符串或 string 模式时,可以使用通知功能来提醒用户。
要监控某个日志 file,您必须满足以下条件:
被监控日志 file 的大小限制取决于 large file support。
请确保在 agent configuration file 中:
配置日志监控 概述。
所有必填输入字段均以红色星号标记。
特别针对日志监控 监控项,您需要输入以下内容:
类型 | 此处选择 Zabbix agent(主动)。 |
键值 | 使用以下 监控项 键之一: log[] 或 logrt[]: 这两个 监控项 键允许监控日志,并根据内容正则表达式(如果存在)过滤日志条目。 例如: log[/var/log/syslog,error] 。请确保 file 对 'zabbix' 用户具有读取权限,否则该 监控项 的状态将被设置为“不支持”。log.count[] 或 logrt.count[]: 这两个 监控项 键仅允许返回匹配行的数量。 有关使用这些 监控项 键及其参数的详细信息,请参见支持的 支持的-监控项-键 键部分。 |
信息类型 | 自动预填: 对于 log[] 或 logrt[] 监控项 - Log ;对于 log.count[] 或 logrt.count[] 监控项 - Numeric (unsigned) 。如果可选地使用 output 参数,您可以手动选择除 Log 以外的适当信息类型。请注意,选择非日志类型的信息将导致丢失本地时间戳。 |
更新间隔(秒) | 该参数定义了 Zabbix agent 检查日志文件中任何更改的频率。将其设置为 1 秒将确保您能尽快 get 新记录。 |
日志时间格式 | 在此字段中,您可以可选地指定用于解析日志行时间戳的模式。支持的占位符: * y: 年(1970-2038) * M: 月(01-12) * d: 日(01-31) * h: 时(00-23) * m: 分(00-59) * s: 秒(00-59) 如果留空,则时间戳将被设置为 Unix 时间中的 0,表示 1970 年 1 月 1 日。 例如,考虑来自 Zabbix agent 日志文件的以下行: " 23480:20100328:154718.045 Zabbix agent 已启动。Zabbix 1.8.2(修订版 11211)。" 它以六个字符位置表示 PID,接着是日期、时间和其他消息内容。 该行的日志时间格式为 "pppppp:yyyyMMdd:hhmmss"。 请注意,"p" 和 ":" 字符是占位符,可以是除 "yMdhms" 以外的任何字符。 |
logrt[]
监控项 且 Zabbix agent 正在遵循其中最新的一个,并且这个最新的一个 最近的日志 file 已被删除,出现警告信息 "there are no files matching "<regexp mask>" in "<directory>"
日志会被记录。Zabbix agent 会忽略修改时间的日志文件 小于agent所见的最近修改时间 对于被检查的 logrt[]
监控项。log[]
或 logrt[]
监控项 的 更新间隔 默认为 1 秒。 agent 将分析不超过 200 条日志 file 记录,并将发送 一次检测中最多匹配 20 条记录到 Zabbix server。 在 agent 配置中增加 MaxLinesPerSecond 参数值 file 或 设置 maxlines 参数在 监控项 键中,可以实现对行数的限制。 增加至最多 10000 条分析日志 file 记录和 1000 条匹配 每次检测中发送到 Zabbix server 的记录数。如果 更新间隔 设置为 2 秒时,单个检查的限制将被设置 2 次 高于 更新间隔 为 1 秒时的值。logrt
使用正则表达式 目录正则表达式匹配不受支持。logrt[]
监控项 变为 NOTSUPPORTED,则表示 日志文件预期所在目录未找到 存在。有时我们可能只想从其中提取出感兴趣的值 使用 target file 而不是在整个行匹配时返回整行 表达式匹配已找到。
日志 监控项 能够提取所需的值 来自匹配的行。这是通过附加的 output(输出)实现的。 参数位于 log
和 logrt
监控项。
使用“output”参数可以指定“捕获组”的 我们可能感兴趣的匹配。
例如,举个例子
应允许返回在以下内容中找到的条目计数:
二月 07, 2014 11:07:36.6690 */ 线程 ID 1400 (GLEWF) 结果过大
缓冲区分配 - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement
仅返回数字,因为 \1 指代第一个和 仅捕获组:([0-9]+)。
并且,通过提取并返回数字的功能,该值可以是 用于定义触发器。
日志监控项中的'maxdelay'参数允许忽略部分较旧的行 从日志文件中以get最近分析的行 'maxdelay' 秒。
将'maxdelay'设置为大于0可能导致忽略 重要日志file记录和遗漏告警。使用时请谨慎 仅在必要时自行承担风险。
默认情况下,用于日志监控的监控项会追踪文件中出现的所有新行 日志文件。然而,某些应用程序在某些情况下 开始在其日志文件中写入大量消息。 例如,如果数据库或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 监控项:"logrt["/home/zabbix32/test[0-9].log",错误,,1000,,,120.0]"
日志文件:"/home/zabbix32/test1.log" 跳过 679858 字节
(从字节75653115到字节76332973)以满足最大延迟
“to byte”数值为近似值,因为在“跳转”后agent 将file中的位置调整至日志行的起始处 可能在file之后或之前。
根据增长速度与增长速度的比较情况 分析日志file时,您可能会发现没有"跳跃"、偶尔或频繁出现"跳跃"的情况 数值出现大幅或小幅"跳跃",甚至每次检查时都出现小幅"跳跃"。 系统负载波动和网络延迟也会影响 延迟的计算,从而“跳跃”前进以跟上进度 "maxdelay" 参数。
不建议将'maxdelay'设置为小于'update间隔'(这可能导致 导致频繁的小幅度"跳跃"。
使用 logrt
与 copytruncate
选项假定不同的日志文件 具有不同的记录(至少时间戳不同), 因此,初始块(最多前 512 字节)的 MD5 校验和将被计算。 不同。两个文件具有相同的初始块MD5校验和,意味着它们的初始块内容相同。 其中之一是原始文件,另一个是副本。
使用 logrt
和 copytruncate
选项可以努力正确地处理 日志 file 会复制内容而不报告重复项。然而,类似以下内容: 生成多个具有相同时间戳的日志 file 副本,日志 file rotation more often than logrt[] 监控项 update interval, frequent 不建议重启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 会被写入两个镜像中。然后 镜像已拆分。在活动的 copy 上,日志 file 仍在增长,正在获取 新记录。Zabbix agent 对其进行分析并发送处理后的日志大小和 修改时间至服务器。在被动 copy 上,日志 file 保持不变。 远远落后于活动副本之后。随后,操作系统和 Zabbix agent 是 从被动副本重新启动。已处理的日志大小和修改时间 从服务器接收的 Zabbix agent 可能不适用于当前情况。 被动复制。要继续从 file 监控的位置进行 agent 留下的工作 off at the moment of 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 状态,此时其持久化文件将变得有用。
如果在 24 小时到期之前 agent 被停止,则过时文件不会被删除,因为 Zabbix agent 不再从 Zabbix server 获取其路径信息。
当 agent 停止时,若将日志 监控项 的 persistent_dir 重新配置回旧的 persistent_dir 路径,而用户未手动删除旧的持久化 file,将导致从旧的持久化 file 恢复 agent 状态,从而可能造成消息遗漏或误报警。
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 应位于与被监控日志文件相同的镜像文件系统上。
如果无法创建 persistent_dir 目录或目录不存在,或者 Zabbix agent 的访问权限不允许创建/写入/读取/delete 文件,则该日志 监控项 将变为 NOTSUPPORTED。
如果在agent操作期间删除了对持久化存储文件的访问权限或发生其他错误(例如磁盘空间已满),则错误将被记录到agent日志file中,但日志监控项不会变为NOTSUPPORTED。
监控项的持久化file在每批数据(包含监控项的数据)成功发送到服务器后都会更新。例如,默认的“BufferSize”为100。如果一个日志监控项发现了70条匹配的记录,则前50条记录将在一个批次中发送,持久化file将被更新;然后剩余的20条记录将在第二个批次中发送(当积累更多数据时可能会有延迟),持久化file将再次更新。
来自 log[]
和 logrt[]
的每一行匹配项 监控项 及其各自的结果 log.count[]
和 logrt.count[]
监控项 检查需要一个空闲的插槽 指定的 50% 区域在 agent 发送缓冲区中。缓冲区的元素是 定期发送到服务器(或proxy),并且缓冲区插槽再次变为空闲。
当 agent 中指定的日志区域仍有空闲插槽时,发送 buffer and communication fails between agent 和服务器(或 proxy)之间 日志监控结果会累积在发送缓冲区中。这有助于 减轻短时通信故障。
在较长的通信故障期间,所有日志插槽 get 都会被占用,并且 采取以下操作:
log[]
和 logrt[]
监控项 检查已停止。当通信恢复时, 当缓冲区中恢复并有空闲插槽可用时,检查将进行。 从上一位置恢复。不会丢失任何匹配的行,它们 只是稍后报告而已。log.count[]
和 logrt.count[]
检查在以下情况下会停止: maxdelay = 0
(默认)。其行为类似于 log[]
并且 logrt[]
如上所述使用 监控项。请注意,这可能会产生影响 log.count[]
和 logrt.count[]
的结果:例如,一个检查 在日志文件中匹配到100行,但没有可用的 缓冲区中的插槽,检查将停止。当通信是 恢复了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 agent监控其自身的日志文件。 例如,如果分析了10记录,并且有3记录因正则表达式运行时错误而失败,则会在agent日志中生成一条记录。
异常:如果最大行数/秒=1 且 update 间隔=1(每次检测仅允许分析 1 条记录),则正则表达式运行时错误不会被记录。
zabbix_agentd 在发生运行时错误的情况下会记录 监控项 键,zabbix_agent2 会记录 监控项 ID,以帮助识别是哪个日志 监控项 出现了运行时错误。 若发生运行时错误,建议重新设计正则表达式。