1 Server

概述

Zabbix 服务器是 Zabbix 软件的核心进程。

服务器执行数据轮询和捕获，计算触发器，并向用户发送通知。 它是 Zabbix agent 和 proxy 上报系统可用性与完整性数据的核心组件。 服务器本身还可以使用简单服务检查，远程检查网络服务（例如 Web 服务器和邮件服务器）。

服务器是存储所有配置、统计和运行数据的中央存储库，也是 Zabbix 中在任何受监控系统出现问题时主动向管理员发出告警的实体。

一个基本的 Zabbix 服务器的运行可分为三个不同的组件：Zabbix 服务器、Web 前端和数据库存储。

Zabbix 的所有配置信息都存储在数据库中，服务器和 Web 前端都会与数据库交互。 例如，当您使用 Web 前端（或 API）创建一个新的监控项时，它会被添加到数据库中的 items 表。 随后，Zabbix 服务器大约每分钟会查询一次 items 表，以获取处于活动状态的监控项列表，然后将其存储到 Zabbix 服务器内部的缓存中。 这就是为什么在 Zabbix 前端中所做的更改，最多可能需要两分钟才会显示在最新数据部分。

服务进程

如果以软件包方式安装

Zabbix 服务器作为守护进程运行。 可通过执行以下命令启动服务器：

systemctl start zabbix-server

这适用于大多数 GNU/Linux 系统。 在其他系统上，您可能需要运行：

/etc/init.d/zabbix-server start

类似地，如需停止/重启/查看状态，请使用以下命令：

systemctl stop zabbix-server
systemctl restart zabbix-server
systemctl status zabbix-server
手动启动

如果上述方法不起作用，则必须手动启动它。 找到 zabbix_server 二进制文件的路径并执行：

zabbix_server

你可以对 Zabbix 服务器使用以下命令行参数：

-c --config <file>              配置文件的路径（默认为 /usr/local/etc/zabbix_server.conf）
-f --foreground                 在前台运行 Zabbix 服务器
-R --runtime-control <option>   执行管理功能
-T --test-config                验证配置文件并退出
-h --help                       显示此帮助信息
-V --version                    显示版本号

使用命令行参数运行 Zabbix 服务器的示例：

zabbix_server -c /usr/local/etc/zabbix_server.conf
zabbix_server --help
zabbix_server -V
运行时控制

运行时控制选项：

Option Description Target
config_cache_reload 重新加载配置缓存。如果当前正在加载缓存，则忽略。
history_cache_clear=target 清除由其 ID 指定的监控项的历史缓存。
影响该监控项的所有值，但第一个值和最后一个值除外。		 target - 监控项的 ID
diaginfo[=<section>] 在服务器日志文件中收集诊断信息。 historycache - 历史缓存统计信息
valuecache - 值缓存统计信息
preprocessing - 预处理管理器统计信息
alerting - 告警管理器统计信息
lld - LLD 管理器统计信息
locks - 互斥锁列表（在 BSD 系统上为空）
connector - 队列最长的连接器统计信息
ha_status 记录高可用性（HA）集群状态。
ha_remove_node=target 移除由名称或 ID 指定的高可用性（HA）节点。
请注意，活动/备用节点无法移除。		 target - 节点名称或 ID（可通过运行 ha_status 获取）
ha_set_failover_delay=delay 设置高可用性（HA）故障切换延迟。
支持时间后缀，例如 10s、1m。
proxy_config_cache_reload[=<target>] 重新加载 proxy 配置缓存。 target - 以逗号分隔的 proxy 名称列表
如果未指定 target，则重新加载所有 proxy 的配置
secrets_reload 从 Vault 重新加载密钥。
service_cache_reload 重新加载服务管理器缓存。
snmp_cache_reload 重新加载 SNMP 缓存——清除所有主机的 SNMP 引擎属性（引擎时间、引擎启动次数、引擎 ID、凭据）。在排查 SNMP 问题时，可用于强制执行全局缓存清除。
housekeeper_execute 启动清理过程。
如果清理过程当前正在进行，则忽略。
trigger_housekeeper_execute 启动触发器清理过程。
如果触发器清理过程当前正在进行，则忽略。
log_level_increase[=<target>] 提高日志级别，如果未指定 target，则影响所有进程。
BSD 系统不支持。		 process type - 指定类型的所有进程（例如 poller）
查看所有服务器进程类型。
process type,N - 进程类型和编号（例如 poller,3）
pid - 进程标识符（1 到 65535）。对于更大的值，请将 target 指定为“process type,N”。
log_level_decrease[=<target>] 降低日志级别，如果未指定 target，则影响所有进程。
BSD 系统不支持。
prof_enable[=<target>] 启用性能分析。
如果未指定 target，则影响所有进程。
启用性能分析后，将按函数名提供所有 rwlocks/mutexes 的详细信息。		 process type - 指定类型的所有进程（例如 history syncer）
支持作为性能分析目标的进程类型：alerter、alert manager、availability manager、configuration syncer、discovery manager、escalator、history poller、history syncer、housekeeper、http poller、icmp pinger、ipmi manager、ipmi poller、java poller、lld manager、lld worker、odbc poller、poller、preprocessing manager、preprocessing worker、proxy poller、self-monitoring、service manager、snmp trapper、task manager、timer、trapper、unreachable poller、vmware collector
process type,N - 进程类型和编号（例如 history syncer,1）
pid - 进程标识符（1 到 65535）。对于更大的值，请将 target 指定为“process type,N”。
scope - rwlock、mutex、processing 可与进程类型和编号一起使用（例如 history syncer,1,processing），也可用于某类型的所有进程（例如 history syncer,rwlock）
prof_disable[=<target>] 禁用性能分析。
如果未指定 target，则影响所有进程。		 process type - 指定类型的所有进程（例如 history syncer）
支持作为性能分析目标的进程类型：参见 prof_enable
process type,N - 进程类型和编号（例如 history syncer,1）
pid - 进程标识符（1 到 65535）。对于更大的值，请将 target 指定为“process type,N”。

使用运行时控制重新加载服务器配置缓存的示例：

zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload

使用运行时控制重新加载 proxy 配置的示例：

# 重新加载所有 proxy 的配置：
zabbix_server -R proxy_config_cache_reload

# 重新加载 Proxy1 和 Proxy2 的配置：
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

使用运行时控制清除某个监控项历史缓存的示例：

zabbix_server -c /usr/local/etc/zabbix_server.conf -R history_cache_clear=42243

使用运行时控制收集诊断信息的示例：

# 在服务器日志文件中收集所有可用的诊断信息：
zabbix_server -R diaginfo

# 在服务器日志文件中收集历史缓存统计信息：
zabbix_server -R diaginfo=historycache

使用运行时控制重新加载 SNMP 缓存的示例：

zabbix_server -R snmp_cache_reload

当通过 Zabbix UI 更新 SNMPv3 接口时，在大多数情况下，Zabbix 会自动为该接口重新加载新的 SNMPv3 凭据；仅当凭据更改后轮询仍然失败时（例如，由于 engineBoots/engineID 不一致或非 RFC 设备），或当您需要为故障排查强制执行全局 SNMP 缓存清除时，才使用 -R snmp_cache_reload。

使用运行时控制触发执行 housekeeper 的示例：

zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute

使用运行时控制更改日志级别的示例：

# 提高所有进程的日志级别：
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase

# 提高第二个 poller 进程的日志级别：
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2

# 提高 PID 为 1234 的进程的日志级别：
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234

# 降低所有 http poller 进程的日志级别：
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

将 HA 故障切换延迟设置为最小值 10 秒的示例：

zabbix_server -R ha_set_failover_delay=10s
运行用户

Zabbix 服务器被设计为以非 root 用户运行。
它将以启动时所使用的任何非 root 用户身份运行。
因此，你可以将服务器作为任意非 root 用户运行，而不会有任何问题。

如果你尝试以“root”身份运行，它将切换到硬编码的“zabbix”用户，该用户必须已在你的系统中存在。
只有在相应修改服务器配置文件中的“AllowRoot”参数后，你才能以“root”身份运行服务器。

如果 Zabbix 服务器和 agent 在同一台机器上运行，建议为服务器和 agent 使用不同的运行用户。
否则，如果两者以同一用户运行，agent 就可以访问服务器配置文件，而 Zabbix 中任何具有管理员级别权限的用户都可以相当容易地获取例如数据库密码之类的信息。

配置文件

有关配置 zabbix_server 的详细信息，请参见配置文件选项。

启动脚本

这些脚本用于在系统启动/关闭期间自动启动/停止 Zabbix 进程。
这些脚本位于 misc/init.d 目录下。

服务器进程类型和线程

  • agent poller - 用于被动检查的异步轮询器进程，带有工作线程
  • alert manager - 告警队列管理进程
  • alert syncer - 告警数据库写入进程
  • alerter - 用于发送通知的进程
  • availability manager - 用于更新主机可用性的进程
  • browser poller - 用于浏览器监控项检查的轮询器
  • configuration syncer - 用于管理配置数据内存缓存的进程
  • configuration syncer worker - 用于解析并同步监控项名称中用户宏值的进程
  • connector manager - 连接器管理进程
  • connector worker - 用于处理来自连接器管理进程请求的进程
  • discovery manager - 用于发现设备的管理进程
  • discovery worker - 用于处理来自发现管理进程的发现任务的进程
  • escalator - 用于执行动作升级的进程
  • ha manager - 用于管理高可用性的进程
  • history poller - 用于处理需要数据库连接的计算型检查的进程
  • history syncer - 历史数据数据库写入进程
  • housekeeper - 用于删除过期数据（监控项历史数据和趋势数据、用户会话、事件等）以及已删除对象遗留数据的进程
  • http agent poller - 用于 HTTP 检查的异步轮询器进程，带有工作线程
  • http poller - Web 监控轮询器
  • icmp pinger - 用于 icmpping 检查的轮询器
  • internal poller - 用于内部检查的轮询器
  • ipmi manager - IPMI 轮询器管理进程
  • ipmi poller - 用于 IPMI 检查的轮询器
  • java poller - 用于 Java 检查的轮询器
  • lld manager - 低级别发现任务的管理进程
  • lld worker - 低级别发现任务的工作进程
  • odbc poller - 用于 ODBC 检查的轮询器
  • poller - 用于被动检查的普通轮询器
  • preprocessing manager - 带有预处理工作线程的预处理任务管理进程
  • preprocessing worker - 用于数据预处理的线程
  • proxy poller - 用于被动 proxy 的轮询器
  • proxy group manager - proxy 负载均衡和高可用性管理进程
  • report manager- 计划报表生成任务的管理进程
  • report writer - 用于生成计划报表的进程
  • self-monitoring - 用于收集服务器内部统计信息的进程
  • service manager - 通过接收来自 history syncer、task manager 和 alert manager 的问题、问题标签及问题恢复信息来管理服务的进程
  • snmp poller - 用于 SNMP 检查的异步轮询器进程，带有工作线程（仅适用于 walk[OID] 和 get[OID] 监控项）
  • snmp trapper - 用于 SNMP trap 的 trapper
  • task manager - 用于远程执行其他组件请求任务的进程（例如关闭问题、确认问题、立即检查监控项值、远程命令功能）
  • timer - 用于处理维护期的定时器
  • trapper - 用于主动检查、trap 和 proxy 通信的 trapper
  • trigger housekeeper - 用于删除由现已删除的触发器生成的问题和事件的进程
  • unreachable poller - 用于不可达设备的轮询器
  • vmware collector - VMware 数据采集器，负责从 VMware 服务收集数据

可以使用服务器日志文件来观察这些进程类型。

服务器日志文件创建时，仅文件所有者具有读写权限。此外，文件所有者所属组具有读取权限。其他所有权限均被拒绝。

可以使用 zabbix[process,<type>,<mode>,<state>] 内部item监控各种类型的 Zabbix 服务器进程。

历史同步器事务统计

history syncer 进程标题会显示有关 history syncer 事务的详细统计信息：

205182 ?        S      0:00  zabbix_server: history syncer #2 [processed 0 values, 0+0 triggers in 0.000021 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]
205183 ?        S      0:00  zabbix_server: history syncer #3 [processed 18 values, 7+0 triggers in 0.002612 (0.001108,0.000000,0.000000,0.001208,0.000014) sec, idle 1 sec]
205184 ?        S      0:00  zabbix_server: history syncer #4 [processed 0 values, 0+0 triggers in 0.000027 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]

在 “A+B triggers” 中：

  • A - 因历史值而处理的触发器；
  • B - 因定时器而处理的触发器。

在 “processed...in N (<timings>) sec” 中，各项时间分别为：

  • 将监控项值写入数据库所花费的时间；
  • 更新监控项数据（状态、错误、主机清单等）所花费的时间；
  • 将趋势数据刷新到数据库所花费的时间；
  • 计算触发器所花费的时间；
  • 处理事件和动作所花费的时间。
清理过程

housekeeper 进程会定期删除过期数据（监控项历史数据和趋势数据、用户会话、事件等），以及已删除对象遗留的数据。 它按周期运行，运行频率和每个周期的删除上限由 HousekeepingFrequency 和 MaxHousekeeperDelete 决定。 在一个周期内未删除的任何数据都会延续到下一个周期。 可在 Administration > Housekeeping 中启用并配置自动清理。

对于删除对象后遗留的数据清理，housekeeper 进程依赖 housekeeper 表中的任务；每当对象被删除时，该表都会被填充。 例如，当您删除一台主机时，Zabbix 也会删除其监控项，但不会删除这些监控项的历史数据、趋势数据或问题。 相反，数据库触发器会向 housekeeper 表中写入任务，这些任务包含以下字段：

  • housekeeperid - 任务 ID
  • object - 对象类型（0 - 监控项；1 - 触发器；2 - 服务；3 - 发现的主机；4 - 发现的服务）
  • objectid - 对象 ID（帮助 housekeeper 查找与对象相关的数据）

例如，删除一台包含两个监控项和一个触发器的主机会按如下方式填充 housekeeper 表：

+---------------+--------+----------+
| housekeeperid | object | objectid |
+---------------+--------+----------+
|             1 |      1 |    28724 |
|             2 |      0 |    59396 |
|             3 |      0 |    59397 |
+---------------+--------+----------+

数据库触发器在填充 housekeeper 表时不会检查是否存在与对象相关的数据；该检查由 housekeeper 进程完成。

每个任务都会产生一个或多个 housekeeper 操作，具体取决于对象类型：

  • 对于监控项（包括 LLD 规则）——从所有包含这些监控项值的历史和趋势表中删除数据（history、history_str、history_log、history_uint、history_text、history_bin、history_json、trends、trends_uint）。 此外，还会检查 problems 表，并删除与这些监控项相关的过期内部事件。

  • 对于触发器——检查与事件相关的表（problem、event_symptom、event_recovery、events），删除与这些触发器相关的过期事件，并将已删除事件通知给 service manager 进程。

单独的 trigger housekeeper 进程负责一个范围更窄的任务——删除没有已知源触发器的问题和事件。 其运行频率由 ProblemHousekeepingFrequency 控制。

在触发器清理过程启动之前，由后来已被删除的触发器引起的问题仍可能生成服务问题并将其分配给服务。如果您的环境中包含许多基于频繁发现/未发现触发器的服务状态计算规则，请考虑通过调整服务器配置参数 ProblemHousekeepingFrequency 来提高该清理过程的运行频率。

  • 对于服务——检查 problems 表，删除过期的服务事件以及过期的服务问题，从而在清理时将其解决。

  • 对于网络发现——从 problems 表中删除过期的发现事件。

housekeeper 仅删除那些未与问题关联的事件。 例如，如果某个过期的问题/恢复事件与一个未关闭的问题相关联，则不会被删除。 当 housekeeper 删除过期实体时，会先删除问题，再删除事件。

使用 partition 模式（TimescaleDB 分区表）的表会被跳过；仅处理使用 regular 模式的表。

支持的平台

由于服务器运行对安全性的要求以及其任务关键型特性，只有 UNIX 操作系统才能持续提供所需的性能、容错能力和弹性。 Zabbix 可运行于市场主流版本之上。

Zabbix 服务器已在以下平台上进行测试：

  • Linux
  • Solaris
  • AIX
  • HP-UX
  • Mac OS X
  • FreeBSD
  • OpenBSD
  • NetBSD
  • SCO Open Server

Zabbix 也可能在其他类 Unix 操作系统上运行。

区域设置

请注意，服务器需要使用 UTF-8 区域设置，以便能够正确解析某些文本监控项。 大多数现代类 Unix 系统默认使用 UTF-8 区域设置；不过，在某些系统中，可能需要专门进行设置。