在 Zabbix 中,您可以为主机组、主机以及特定的触发器或服务定义维护期。
Zabbix 提供两种维护类型 - 有数据收集(with data collection)和没有数据收集(with no data collection)。
在“有数据收集”的维护期间,触发器会像平常一样进行处理,并在需要时创建事件。然而,如果在操作配置中勾选了“暂停操作以解决被抑制的问题(Pause operations for suppressed problems)* 选项,则会暂停维护中的主机/触发器的问题升级。在此情况下,包括发送通知或远程命令的升级步骤将被忽略,维护期间持续期间内不会执行这些步骤。需要注意的是,问题的恢复和更新操作在维护期间不会被抑制,只有升级操作会被暂停。
例如,如果在问题发生后的0、30和60分钟安排了升级步骤,并且在实际问题发生后进行了30分钟的维护,那么第二步和第三步将会延迟半小时执行,即在60分钟和90分钟时执行(前提是问题仍然存在)。同样地,如果在维护期间出现了问题,升级步骤会在维护结束后开始执行。
如果要在维护期间正常接收问题通知(无延迟),需要在操作配置中取消勾选“暂停抑制问题的操作”选项。
在触发器表达式中使用的主机,只要至少有一个主机未处于维护模式中,Zabbix 将发送问题通知。
Zabbix server 在维护期间必须保持运行状态。维护期每分钟重新计算一次,或者在配置缓存重新加载时进行。如果维护期间有更改,定时器进程会在每分钟的0秒检查是否需要更改主机状态进入或退出维护模式。此外,每秒钟定时器进程会根据配置更新的间隔(默认为10秒)检查是否需要开始或停止任何维护期。因此,启动或停止维护期的速度取决于配置更新间隔。
需要注意的是,维护期更改不包括“自激活时间/自停止时间”设置。另外,如果将主机或主机组添加到现有的活动维护期中,这些更改将在下一分钟开始时由定时器进程激活。
当主机进入维护模式时,Zabbix Server定时器进程将读取所有未解决的问题以确定是否需要抑制这些问题。如果存在许多未解决的问题,这可能会对性能产生影响。此外,即使在此时没有配置维护期,Zabbix server 在启动时也会读取所有未解决的问题。
需要注意的是,Zabbix Server(或proxy)始终会收集数据,无论维护类型如何(包括“无数据”维护)。如果设置了“无数据收集”,server 会忽略后来的数据。
当“无数据”维护结束时,使用 nodata() 函数的触发器在它们检查期间不会在下一次检查之前触发。
如果在主机处于维护状态时添加了日志项,并且维护结束后,只会收集自维护结束后的新日志条目。
如果在“无数据”维护类型中为主机发送了时间戳值(例如使用Zabbix sender),则该值将被丢弃。然而,可以在维护期已过期的情况下发送时间戳值,系统将接受该值。
如果用户更改了维护期、主机、主机组或标签,则这些更改只会在配置缓存同步后生效。
配置维护期有以下操作步骤:
所有必填字段都标有红色星号。
参数 | 描述 |
---|---|
名称 | 维护期的名称。 |
维护类型 | 可设置两种维护类型: 带数据收集 - 维护期间服务器会收集数据,并处理触发器; 无数据收集 - 维护期间服务器不会收集数据。 |
生效时间 | 维护期生效的日期和时间。 注意: 单独设置此时间并不会激活维护期;必须在时间段中配置维护期(详见下文)。 |
结束时间 | 维护期结束的日期和时间。 |
时间段 | 这个部分允许您定义维护期间确切的天数和小时。点击![]() |
主机组 | 选择要激活维护期的主机组。维护期将对指定主机组中的所有主机生效。此字段支持自动完成,开始输入时将显示所有可用的主机组下拉列表。 隐式选择父主机组会同时选择所有嵌套的主机组。因此,维护期也将在嵌套组的主机上生效。 |
主机 | 选择要激活维护期的主机。此字段支持自动完成,开始输入时将显示所有可用的主机下拉列表。 |
标签 | 如果指定了维护标签,将会激活所选主机的维护期,但只会抑制匹配标签的问题(即不会执行任何操作)。 对于多个标签,计算方法如下: And/Or - 所有标签必须对应;但标签具有相同标签名称的情况下,按Or条件计算; Or - 只需要一个标签对应即可。 有两种标签值匹配方式: 包含 - 区分大小写的子字符串匹配(标签值包含输入的字符串); 等于 - 区分大小写的字符串匹配(标签值等于输入的字符串)。 仅在选择了带数据收集模式时才能指定标签。 |
描述 | 维护期的描述。 |
维护期时间窗口用于安排定期或一次性维护的时间。该表单是动态的,根据选择的周期类型不同,可用字段会发生变化。
周期类型 | 描述 |
---|---|
仅一次 | 配置仅一次的维护期: 日期 - 维护期开始的日期和时间; 维护期长度 - 维护期持续时间。 |
每天 | 配置每日维护期: 每天(s) - 维护频率(1 - (默认) 每天,2 - 每两天,以此类推); 在 (小时:分钟) - 维护开始的时间; 维护期长度 - 维护期持续时间。 当每天(s)参数大于 "1" 时,起始日期是生效时间所在的日期。例如: - 如果生效时间设置为 "2021-01-01 12:00",每天(s)设置为 "2",在 (小时:分钟) 设置为 "23:00",则第一个维护期将于1月1日23:00开始,第二个维护期将于1月3日23:00开始; - 如果生效时间设置为 "2021-01-01 12:00",每天(s)设置为 "2",在 (小时:分钟) 设置为 "01:00",则第一个维护期将于1月3日01:00开始,第二个维护期将于1月5日01:00开始。 |
每周 | 配置每周维护期: 每周(s) - 维护频率(1 - (默认) 每周,2 - 每两周,以此类推); 星期几 - 维护应该在哪一天进行; 在 (小时:分钟) - 维护开始的时间; 维护期长度 - 维护期持续时间。 当每周(s)参数大于 "1" 时,起始周是生效时间所在的周。详见上述每天参数描述中的示例。 |
每月 | 配置每月维护期: 月份 - 选择进行定期维护的所有月份; 日期:月中的某一天 - 如果维护应在每月同一日期进行(例如,每月1日),然后在出现的月中的某一天字段中选择所需的日期; 日期:每周的某一天 - 如果维护应仅在某些特定日子进行(例如,每月第一个星期一),然后在下拉菜单中选择所需的月份(第一、第二、第三、第四或最后一周),然后标记维护日的复选框; 在 (小时:分钟) - 维护开始的时间; 维护期长度 - 维护期持续时间。 |
在创建维护期时,使用创建者的时区。 然而,当选定维护周期(每天、每周、每月)时,会使用使用 Zabbix Server的时区。 为确保重复维护期内的可预测行为,需要在为Zabbix 的所有部分分配使用统一的时区设置。
完成后,点击添加将维护期添加到周期板块。 请注意,夏令时(DST)变化不会影响维护的持续时间.例如,假设我们配置了一个两小时的维护期,通常从01:00开始,到03:00结束: - 如果在维护进行了一小时后(在02:00时),发生了夏令时变化,当前时间从02:00调整到03:00,那么维护将继续进行一小时,直到04:00; - 如果在维护进行了两小时后(在03:00时),发生了夏令时变化,当前时间从03:00调整到02:00,那么维护将停止,因为已经过了两小时; - 如果维护期开始时间落在夏令时变化时跳过的那一小时内,维护将不会开始。
如果一个维护期被设置为“1天”(实际维护期为24小时,因为Zabbix将每天按小时来计算),从00:00开始,到第二天的00:00结束: - 如果当前时间向前调整了一小时,那么维护将在第二天的01:00停止; - 如果当前时间向后调整了一小时,那么维护将在当天的23:00停止。
主机名旁边的橙色扳手图标 表示该主机正在维护中:
将鼠标指针悬停在图标上时会显示维护详细信息。
此外,维护中的主机在监控(Monitoring) → 拓扑图(Maps)中显示为橙色背景。
通常,维护中的主机问题会被抑制,即不会显示在前端。但是,也可以通过在以下位置选择 显示抑制的问题 选项来配置显示抑制的问题:
显示抑制的问题时,会显示以下图标:。将鼠标悬停在图标上会显示更多详细信息:
Queues displayed in the Zabbix frontend (Administration > Queue) are calculated by the Zabbix server. They do not include items under maintenance with no data collection—queue length is always zero for these items even when their values are delayed. Delayed items in maintenance with data collection are still counted in the queue.
The Zabbix proxy is not aware of maintenance periods because there is no synchronization of maintenance configuration between the Zabbix server and proxy. Internal checks calculated on Zabbix proxies (for example, zabbix[queue,,]
and zabbix[stats,,,queue,,]
) report delayed items regardless of the maintenance status on the Zabbix server.
As a result, different queue lengths may be reported for the same items in maintenance with no data collection by the Zabbix frontend and by internal checks on Zabbix proxies.