开源监控系统中 Zabbix 和 Nagios 哪个更好?

关注者
2602
被浏览
365825

46 个回答

我比较看好zabbix这款监控软件,理由如下:
1.分布式监控,天生具有的功能,适合于构建分布式监控系统,具有node,proxy2种分布式模式
2.自动化功能,自动发现,自动注册主机,自动添加模板,自动添加分组,是天生的自动化运维利器的首选,当然于自动化运维工具搭配,puppet+zabbix,或者saltstack+zabbix,那是如鱼得水。
3.自定义监控比较方便,自定义监控项非常简单,支持变量,支持low level discovery,可以参考我写的文档自动化运维之监控篇---利用zabbix自动发现功能实现批量web url监控
4.触发器,也就是报警条件有多重判断机制,当然,这个需要你去研究一下,这也是zabbix的精华之处,
5.支持多种监控方式,agentd,snmp,ipmi,jmx,逻辑图如下
6.提供api功能,二次开发方便,你可以选用zabbix来进行二次深度开发,结合cmdb资产管理系统,业务管理系统,从而使你的自动化运维系统达到新的高度。
7.当然zabbix还有很多其他功能,这里不一一介绍了。
很多人说zabbix不简单,其实是zabbix的设计理念有些超前,当你都研究到一定程度,你不得不佩服zabbix的团队是非常强悍的,这种工作机制也是相对先进的。
国内的大厂,都有一套自己的监控系统,自己设计,自己开发,其功能也能和zabbix一样,更能适合于自己的需求,但一般企业用,特别是中型互联网公司,还是极力推荐zabbix。
另外附上我的文档Zabbix使用手册V1.4.pdf,这里面有我的经验总结,以及一些使用心得与技巧
最后建议大家多看官方文档
新浪微盘下载地址:最新文档版本为Zabbix使用手册V2.0.pdf
百度网盘下载地址:Zabbix使用手册V2.0.pdf_免费高速下载

同时提供zabbix的安装二次定制的RPM包,该项目地址为:
github.com/itnihao/zabb
广告一下, 本人新书已经出版,欢迎围观 Zabbix企业级分布式监控系统

首先,提醒一下大家。下面的内容,有可能会被认为是广告,因为我推荐的是我自己做的一款产品:Cloud Insight


但是,在对比 Zabbix 和 Nagios 的时候,我觉得有些东西还是值得拿出来讨论一下的。


第一个就是上文 Wenx 提到的:没有更好,只有更适合吧。

是否需要使用 Zabbix 或者 Nagios 都是可以拿出来讨论讨论的。在人员不够、经验不足、时间很紧的情况下,有必要使用 Zabbix 或 Nagios 这样很重的解决方案吗?


Zabbix 和 Nagios 相继出现在 1998 年和 1999 年,经过历史的发展和迭代,以及社区中很多程序员的贡献,已经发展得很强大了。


我们 OneAPM 公司初期也是使用 Zabbix 来做所有云主机和物理主机的监控。但是后期遇到了很多大的麻烦:

  1. 用 Zabbix 和 Nagios 真的很依赖运维工程师的实际水平
  2. Docker Mesos 这些新技术的支持,需要自己去找脚本来试验,真的很麻烦
  3. 数据是只读的,运维工程师真的就只是看看,出啥问题了,最后还是重启,从腾讯云换到阿里云等等这种麻烦的手段

既然监控是为了解决实际的问题,并且基于找到自己最适合的运维监控工具,那么我推荐一些还在观望 Zabbix 和 Nagios 的初创团队,可以试一试 Cloud Insight。


All in One


就像 esty 当年发布 statsd 写的文章一样:Measure Anything, Measure Everything。系统监控工具如果能够做到 All in One,那真的可以解决人力和时间成本上的问题。


说到这个就得提提 statsd。statsd 是 Flickr 公司首创,后来由 Esty 公司重构的一个轻量级的指标采集模块。


也就是说操作系统、不同数据库、不同的中间件 ,都可以通过它来采集指标,并且上传至 Graphite 这些用于可视化 & 存储的组件中。


不了解的人,可以读读 Measure Anything, Measure Everything


现在很多公司都开始使用了这样的工具,来搭建自己的运维监控系统了。国外也出现了基于 statsd 的公司:Boundary Datadog 等等。以下是他们的网址:

国外这些公司就是为了提供一个一体化的解决方案:如何集成不同的操作系统、数据库、中间件监控的问题,你不需要担心;用就行了。


数据只读和数据管理


就像上文提到的,数据只读是 Zabbix 一个比较大的痛点:根本发现不了什么问题。


所以国内的淘宝、小米都开始使用时间序列数据库,来解决这个事情。


能够对数据对切片、聚合,并且使用一些数值计算,能够更快地解决问题。


拿 Docker 来说,不同的 Container 的 CPU 消耗,这个需求就很常见。标签信息在时间序列数据库中的作用,就是为了解决这个需求。


那么计算是什么意思呢?相信动态门限的告警、对某些数值浮动较小的数值求 log 这些需求在实际运维场景中也是很常见的。


而这些时间序列数据库都可以帮你做到。


Cloud Insight


Cloud Insight 就是国内利用 statsd 和 OpenTSDB 实现的一个一体化的解决方案(免费但不开源)。


楼主提出这个问题, 我猜想是公司内部有人对于 Zabbix 和 Nagios 不是很熟悉,不知道前方有什么坑。 那么,在人员的经验不足的前提下,也没有时间去试错。


所以建议使用下 Cloud Insight 进行快速试错,也看看新的技术发展是否能够更好地满足自己的需求。


最后是上几张产品截图:



总的来说,不建议创业团队或者初创公司,在人员不足的情况下,使用 Zabbix 和 Nagios(成本实在太高)。倒是可以使用国外的这种方法:

轻量级的探针采集数据(Statsd)+ 时间序列数据库(运算)+ 展现端(Grafanna)

或者使用 Cloud Insight,来解决。