1、Zabbix是什么？

首先是定性，zabbix提供了全套的监控解决方案，即采集数据——存储和展示数据——定义告警触发条件——触发告警，这样一个完整的监控流程（在zabbix里对应的术语，也及配置流程为：主机——监控项——触发器——动作，zabbix中的主机是个泛称，泛指任意类型的被监控对象）。

在一些基本场景下，可以做到拿来就用。但zabbix并不死板，在上述四个阶段都可以灵活定制。我自己亲身经历的从nagios迁移到zabbix的过程，让我深刻体会到这是一个既灵活又简单的系统。Nagios社区的所有监控插件，都可以完美地用到zabbix中，且配置更为快捷。

2、如何采集监控数据？

如何采集数据，可以由我们自己天马行空地发挥。zabbix支持非常丰富的数据采集方式，既可以在服务端从被监控端拉取数据（方式包括zabbix agent、snmp、http、ssh、ODBC等等），也可以从被监控端或者任何其他地方向服务器端推送数据（对应的监控项类型为 zabbix agent active、zabbix trapper）。这意味着zabbix的监控能力绝不仅限于其web端展示的那些，而是可以监控你用任意方式采集到的任意数据。

3、配置告警的触发条件需要注意什么？

zabbix的告警触发条件配置十分灵活。但是，不建议配置过于复杂，简单的触发条件才能最大可能地避免误触发或者关键时候未触发。能够配置简单触发条件的前提是提供监控数据要足够简单，比如一个数字、一个字符串，而不应当一段文字、N个数字。

4、zabbix支持什么告警方式？应当选择什么告警方式？

触发告警的动作，即告警要以何种方式发送给何人，在zabbix里也是可以灵活定义的。如最基本的邮件告警，短信告警，最近几个版本增加的webhook告警等等，也可以选择自定义脚本，基本上能够想到的告警方式都可以实现。

至于选择什么样的告警方式，要去取决于实际接收人的使用习惯，比如公司爱用微信办公，就可以把基本告警配置为企业微信告警；公司爱用邮件办公，就使用邮件告警；爱用钉钉办公，就可以试下webhook机器人。

5、告警应当发送给什么人？如何做到不同的告警发送给不同的人？

告警应当发送给对应的负责人，比如A项目的告警发送A项目的负责人甲，B项目的告警发送B项目的负责人乙，而不应当把A项目的告警发送给甲、乙，告警乱发的后果就是长此以往，接收人将不在对告警有敏感性，很有可能错过重要告警。

要做到不同的告警发送给不同的人，在创建主机时要合理的分配“主机群组”，不同项目的主机放到不同的群组下，不同类型的主机放到不同的群组下，这样我们在配置“动作”时，就可以用最简单的条件精准的推送告警。

6、zabbix的触发器严重性级别有什么用？如何选择严重性级别？如何做到不同的严重性级别采用不同的告警方式？

这三个问题是强相关的，我合在一起回答。触发器的严重性级别，不是简单用来在告警内容中显示的，它最大的用处是用来配置“动作”，将不同级别的告警用逐渐升级的方式发送给不同的人。

无需处理的告警，级别可定为信息；需要处理，但不紧急的告警，级别可定为警告；急需处理，但不影响业务的告警，级别可定为严重；急需处理，且已影响某一功能模块的告警，级别可定为严重；万分紧急，可导致业务瘫痪的告警，可定为灾难。

以上级别的告警，对应的告警推送手段可为邮件——短信——电话，推送人可为直接负责人——组长——分管领导——领导。定义好触发的严重性级别，就可以在配置动作时方便地实现不同级别的告警采用不同的方式。

7、监控系统如何做到高可用？

这是一个通用的问题，与监控系统无关。业务系统如何做高可用，监控系统依葫芦画瓢就行，没有特殊的地方。甚至，你可以直接建设两套相同的监控系统，zabbix的agent端和proxy都支持配置多套server。

8、在使用的zabbix agent时，passive模式和active模式有什么区别？如何选择？网络上如何配置？

passive模式下，数据由server主动向agent索取；active模式下，数据由agent主动向server推送；（可以类比为http方法的get、post）。proxy与server的关系与之相同。

选择何种方式见仁见智，一般性原则为：所有agent尽可能配置为passive模式，所有proxy推荐选择active模式，这样在web端可以清晰地显示agent的在线状态，也不会对server造成太大压力。当然如果监控数量不多，全部选择passive模式也是很好的，因为passive模式下，无需考虑时间同步问题。在zabbix中，passive模式下的监控数据时间是以server/proxy的本地时间为准的，active模式下的监控数据时间是已agent本地时间为准的。所以如果使用active模式，必须保证各节点间的时间同步。

如果使用passive模式，则agent所在节点需开放10050端口入访权限，而无需开放出访权限，相对应的只需给server端开放出访权限。此时就可以在agent配置文件中注释掉ServerActive=*，以避免额外的消耗主机性能及日志报错。

如果使用active模式，则server所在节点需开放10051端口入访权限，无需开放出访权限，相对应的agent端只需要开放出访权限。此时就可以将agent配置文件中的StartAgents=3调整为StartAgents=0，以避免额外的端口暴露和性能消耗。

9、zabbix agent配置文件中的hostname一定要和web端一致吗？

不一定。如果agent使用的是passive模式，则该字段没有用处，也无需与web端一致。但如果agent使用的是active模式，则两端必须保持一致，否则agent将不知道数据发往何处。

虽然如此，但仍建议两端保持一致。

10、zabbix应部署在何处？

应部署在网络通达，极可能拥有上帝视角的地方。举个例子，比如树形网络，zabbix就应当部署在根处，这样某一分叉发生故障可以很容易地判断。如果是网形网络，则部署在任何方便的地方都差不多，尽可能保障到各节点网络畅通即可。

11、主机可见名称的定义原则？

建议采用：项目_用途_IP_(负责人_电话)这样的命名形式，好处很多，用了就知道。

12、告警的内容如何定义？

如果采用邮件形式，则标题要简洁且包含关键信息，举个例子：“A项目B主机磁盘空间将满”，这样的标题让我们可以在不打开邮件的情况下就可直接去处理故障了，相比一句简单的“磁盘空间告警”显然要优秀很多。如果使用电话告警，则只需播报关键信息即可，而不要长篇大论，在关键时间让人员电话占线。

详细的内容附在正文，重要信息除了标题中列出的内容外，还应包括告警触发/恢复时间，当时监控项的具体数据，还可附上相关的监控图表。

13、一个小细节，阈值的设定？

对于磁盘空间这类数据存在波动性的监控项，相关的告警和恢复阈值，不应当简单地配置成剩余空间小于10%告警，大于10%恢复。而应当配置为小于10%告警，大于15%恢复。否则当数据在10%左右波动的时候，会不断地触发告警/恢复。

14、zabbix agent有何用？

除了直接提供一些基本的监控项外，还可以很容易的添加一些自定义监控项，只需要在配置文件中指定key和数据获取命令即可。

暂时先想到这么多，以上仅是一些经验性思考，欢迎大家指正。详细的技术细节，如果大家有疑问，也欢迎探讨。

本文出处：代码的荣耀
原文链接：http://www.icoder.top/blog
作者/译者：zhangrj