【QA】Zabbix 答疑精选

以下是 Top 20 Zabbix 常⻅问题及其处理⽅法的问答精选，了解更多信息/参与官方答疑，请联系小Z：17502189550（同微信）。

Q1

Zabbix Server前端显⽰“Zabbix server is not running”，但后台服务进程正常，是什么原因？

A

这通常是由于Zabbix前端配置⽂件（zabbix.conf.php）中的数据库连接参数（$DB['SERVER']）与Zabbix Server配置⽂件（zabbix_server.conf）中的DBHost参数不⼀致导致的。请检查并确保两者配置的数据库主机地址完全⼀致，修改后⽆需重启服务即可⽣效。

Q2

Zabbix Proxy配置缓存使⽤率超过75%告警，应如何调整？

A

需要调整Zabbix Proxy的CacheSize参数。该参数⽤于配置存储主机、监控项等配置数据的共享内存⼤⼩。应根据监控规模及操作系统可⽤内存合理设置，常⻅值为1G〜2G。调整后需重启Zabbix Proxy服务使配置⽣效。

Q3

主机报错 “Get value from agent failed: Cannot establish TCP connection... [113] No route to host”，是什么原因？

A

该报错表⽰Zabbix Server/Proxy⽆法与⽬标主机上的Zabbix Agent建⽴TCP连接，通常是⽹络不通导致的。例如两端不在同⼀⽹络、路由不可达，或中间防⽕墙/安全组未放⾏Agent的10050端⼝。建议使⽤telnet或nc命令测试⽬标主机的10050端⼝连通性。

Q4

Agent被动模式连接被拒绝，报错 “Received empty response from Zabbix Agent... Assuming that agent dropped connection because of access permissions”，如何解决？

A

此报错通常由Zabbix Agent的访问控制⽩名单配置不当导致。请按以下步骤排查：

1. 检查Agent端⽇志（如zabbix_agentd.log），查找类似“connection from ‘<IP>’ rejected” 的记录，确认被拒绝的请求源IP。
2. 编辑Agent配置⽂件zabbix_agentd.conf，将上述源IP添加到Server配置项中（多个IP⽤逗号分隔）。
3. 保存配置并重启Zabbix Agent服务。

Q5

⽇志监控项（log或logrt）采集数据出现⻓时间延迟，例如7点的⽇志到11点才采集到，为什么？

A

这通常是由于⽇志⽂件过⼤，⽽Zabbix Agent的MaxLinesPerSecond参数（默认20）限制了每秒向Server/Proxy发送的最⼤⽇志⾏数。建议根据实际⽇志量适当调⾼此参数值，并缩短⽇志监控项的采集间隔以提⾼频率。

Q6

触发器表达式使⽤了nodata()函数，但监控项有数据时仍误报警，可能是什么原因？

A

可能是数据⼊库延迟导致的。nodata()函数设置的时间窗⼝太短（例如2分钟），在数据正常但稍有延迟时可能产⽣误报。建议根据监控项的实际采集频率和数据延迟情况，适当延⻓nodata()函数的时间窗⼝。

Q7

使⽤⾃动发现规则（LLD）时，报错 “Cannot create item: item with the same key already exists”，如何解决？

A

这通常是因为在监控项原型中使⽤了低级发现宏（如{#KEY}），但宏定义不正确（例如字⺟未⼤写）或被错误地识别为普通字符串，导致⽣成重复的键值。请检查并确保宏的语法正确，且在中括号内使⽤。

Q8

历史问题⻚⾯点击“配置”后，跳转的触发器名称与事件名称完全不同，如何排查？

A

这⼤概率是因为问题事件⽣成后，在未关闭前，对应的触发器名称被⼈为修改过。Zabbix中事件名称⼀旦⽣成就会固定，不会随触发器名称的后续变更⽽更新。可通过数据库查询该事件对应的objectid，并与当前触发器的triggerid对⽐来确认。

Q9

⽇志中出现报错 “preprocessing failed for: ... cannot extract value from json by path ...: no data matches the specifified path”，是什么意思？

A

该报错表⽰JSON预处理步骤失败，因为指定的JSON路径（如 "$.avg_updatelatency"）在返回的数据中找不到匹配项。请检查监控项返回的原始数据格式，确认JSON路径表达式是否正确，或数据本⾝是否缺少预期字段。

Q10

进⾏DNS解析监控时，使⽤net.dns [,www.baidu.com,ANY] 获取到的值为0，但⼿动测试解析正常，可能是什么原因？

A

这通常是因为DNS协议层⾯对ANY查询类型的处理差异。许多DNS服务器为防御放⼤攻击，会对ANY查询实施限制或返回最⼩化响应。建议将监控项改为明确的记录类型（如A、AAAA），或使⽤默认缺省⽅式 net.dns[,www.baidu.com]。

Q11

如何监控MySQL单机多实例？

A

建议采⽤“实例分⽴ + ⽇志聚合”策略：

1. 实例监控：在Zabbix中为每个MySQL实例创建独⽴的主机，通过IP+不同端⼝或⾃定义宏({$MYSQL.SOCK})区分。每个实例主机关联标准MySQL监控模板。
2. ⽇志监控：创建⼀个专⻔的⽇志监控模板，关联到服务器的OS监控主机上，通过设置不同路径参数集中管理各实例的错误⽇志或慢查询⽇志。

Q12

Zabbix Agent启动失败，报错“cannot create semaphore set: [28] No space left on device”，如何解决？

A

这是系统信号量限制不⾜所致。解决⽅法：

1. 增⼤系统信号量限制：编辑/etc/sysctl.conf，增加kernel.sem = 500 64000 64 256，执sysctl -p⽣效。
2. 清理Zabbix运⾏⽤⼾的残留信号量：执⾏ipcs -a [8](@context-ref?id=25)| grep <zabbix_user> | awk '{print $2}' | xargs -n1 ipcrm -s。

Q13

使⽤Zabbix Proxy后，测试可以正常取值，但历史记录为空，为什么？

A

最常⻅的原因是多个Zabbix Proxy共⽤了同⼀个数据库。每个Zabbix Proxy都必须使⽤独⽴的数据库，否则会导致数据覆盖、冲突，最终出现取值正常但记录为空的情况。

Q14

触发器告警后频繁在恢复与问题状态之间波动（例如CPU使⽤率在95%阈值附近波动），如何优化？

A

可以为触发器配置 “恢复表达式”（Recovery expression）。例如，设置当CPU使⽤率**不低于90%**时才恢复告警，这样就能在阈值附近建⽴⼀个缓冲带，避免因临界值微⼩波动造成的频繁告警与恢复。

Q15

监控项报错 “Unsupported item key for this item type.”，如何排查？

A

该报错的核⼼原因是选择的 “监控项类型” 与输⼊的 “键值（Key）” 格式不匹配。例如，当监控项类型设为 “SSH agent”时，键值必须遵循ssh.run[,,,]的标准格式。请检查并确保键值语法符合所选监控项类型的要求。

Q16

可计算监控项（Calculated item）依赖的其他监控项停⽌采集时，如何让可计算监控项也停⽌计算？

A

Zabbix原⽣⽆法实现⾃动停⽌。⽬前只能⼿动禁⽤该可计算监控项。建议监控依赖项的状态，在其失效时采取⼿动或脚本化操作进⾏⼲预。

Q17

如何从Zabbix 4.0 升级 到 7.0 并迁移主机（约100台）？

A

可以使⽤Zabbix⾃带的导⼊导出功能，步骤⼤致如下：

1. 在Zabbix 7.0 中⼿动创建同名的主机组。
2. 从Zabbix 4.0 中导出模板，并导⼊到Zabbix 7.0。
3. 从Zabbix 4.0 中导出主机，并导⼊到Zabbix 7.0。
4. 修改所有Agent配置⽂件中的Server和ServerActive字段指向新的Server/Proxy地址，并重启Agent服务。

Q18

⽇志中出现报错 “Cannot parse proxy data from active proxy at ...：proxy ... not found”，是什么意思？

A

该报错通常出现在主动模式下，表⽰Zabbix Server收到了来⾃Proxy的数据包，但在数据库中检索不到对应的Proxy记录。最常⻅的原因是Proxy配置⽂件（zabbix_proxy.conf）中的Hostname参数值，与Zabbix Web⻚⾯中定义的 “Proxy name” 不匹配。请务必检查并确保两者字符串完全⼀致（区分⼤⼩写）。

Q19

监控项获取到的中⽂字符显⽰为乱码，如何处理？

A

有以下⼏种思路：

1. 更换为英⽂：将监控项的值改为英⽂或拼⾳，这是最根本的避免乱码的⽅法。
2. 使⽤值映射：如果中⽂内容较少且固定，可以为监控项配置值映射，将乱码值映射为正确的中⽂显⽰。
3. 使⽤预处理：对于变化较⼤或复杂的场景，可使⽤预处理结合JavaScript脚本，将获取到的⼗六进制或编码字符串转换为可读⽂本。

Q20

Zabbix数据库磁盘空间增⻓过快，如何定位和优化？

A

存储消耗主要取决于数据采样频率、历史/趋势数据保留时⻓。建议：

1. 定位⼤监控项：通过特定SQL查询（可参考知识库中提供的链接）找出哪些监控项产⽣的数据量异常⼤。
2. 优化保留策略：在“管理”→“常规”→“Housekeeping”中，合理缩短各类历史数据和趋势数据的保留时间。
3. 启⽤表分区：对于MySQL/PostgreSQL，可以使⽤表分区功能来⾼效管理历史数据的⾃动清理。
4. 检查监控项配置：优化采集频率过⾼或不必要的监控项。