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

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

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

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

 

1. 从运营商接入端理清网络拓扑结构 (边界设备-核心设备-交换机-终端)
2. 使用LLDP发现协议或者结合关停设备地址IP或MAC的方式判断接入的交换机
3. 理清网段、网关、VLAN、DHCP网络资源的划分, 记录为表格文档.
4. 理清每个限制策略 QoS、ACL、Firewall、NAT、的影响范围
5. 网络设备分类编号、接线贴上标签、画拓扑结构图、网络拓扑看板
6. dhcpsnooping 核心链路冗余 设备和链路监控 zabbix speedtest
7. 收集设备信息, 告警通知, 日志记录, 生成监控报表
8. 收集问题, 分析问题, 解决问题, 写记录, 写报告
9. MAC绑定地址认证, 指定主机限速, 行为管控
10. 网络分层分平面 (生产网+办公网+无线网+安防网)

 

1.硬件监控。

通过SNMP来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其他，可以通过IPMI来实现。当然如果没有硬件全都是云，直接跳过这一步骤。

2.系统监控。 

如CPU的负载，上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode节点。当然这些都是需要配置触发器，因为默认太低会频繁报警。

3.服务监控。

比如公司用LNMP nginx自带Status模块、PHP也有相关的Status、MySQL的话可以通过percona来进行监控。Redis这些通过自身的info获信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容，以及报警和图形功能。

4.网络监控。

如果是云主机又不是跨机房，那么可以选择不监控网络。当然你说我们是跨机房以及如何如何。推荐使用smokeping来做网络相关的监控。或者直接交给你们的网络工程师来做。因为术业有专攻。

5.安全监控。

如果是云主机可以考虑使用自带的安全防护。当然也可以使用iptables。如果是硬件，那么推荐使用硬件防火墙。使用云可以购买防DDOS，避免出现故障导致down机一天。如果是系统，那么权限、密码、备份、恢复基础的方案要做好。web同时也可以使用nginx+waf来实现一个web层面的防火墙。当然也可以使用集成好的openresty。

6.Web监控。

web监控的话题其实还是很多。比如可以使用自带的web监控来监控页面相关的延迟、js响应时间、下载时间、等等。这里我推荐使用专业的商业软件，听云来做这一块。毕竟人家全国各地都有机房。（如果本身是多机房那就另说了）

7.日志监控。

如果是web的话可以使用监控Nginx的500x日志。PHP的ERROR日志。其实这些需求无非是，收集、存储、查询、展示，我们其实可以使用开源的ELKstack来实现。ogstash（收集）、elasticsearch（存储+搜索）、kibana（展示）

8.业务监控。

我们上面做了那么多，其实最终还是保证业务的运行。这样我们做的监控才有意义。所以业务层面这块的监控需要和开发以及总监开会讨论，监控比较重要，如API、等。（需要开会确认）然后通过简单的脚本就可以实现，最后设置触发器即可

9.流量分析。

平时我们分析日志都是拿awk sed xxx一堆工具来实现。这样对我们统计ip、pv、uv不是很方便。那么可以使用百度统计、google统计、商业，让开发嵌入代码即可。当然避免隐私也可以使用piwiki来做相关的流量分析。

10.可视化。

通过screen以及引入一些第三方的库来美化界面，同时我们也需要知道、订单量突然增加、突然减少。或者说突然来了一大波流量，这流量从哪儿来，是不是推广了，还是被攻击了。可以结合监控平来来梳理各个系统之间的业务关系。

11.自动化监控。

如上我们做了那么多的工作，当然不能是一台一台的来加key实现。可以通过Zabbix的主动模式以及被动模式来实现。当然最好还是通过API来实现。

All in One

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

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

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

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

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

• Cloud Monitoring as a Service
• TrueSight Pulse (Boundary)

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

数据只读和数据管理

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

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

• 淘宝使用 OpenTSDB 案例：OpenTSDB监控系统的研究和介绍 « 搜索技术博客
• 小米开源项目：Open-Falcon|互联网企业级监控系统

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

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

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

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

Cloud Insight

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

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

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

最后是上几张产品截图：

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

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