监控系统那些事儿00——大纲构思

工作8年了，一直想就监控方面写一些总结性的文字，但总是不知道该从何说起，迟迟没有动笔。纠结再三，干脆以时间线来记录这么多年在监控方面的点滴吧。

好奇，了解HP Openview系列软件

刚来公司的那会儿，公司刚上ITSM项目不久，在兼职流程管理的同时，也在管理运维相关的工具平台。我们所使用的系统以HP Openview系列软件为主，当时没有注意，但是后来通过Google搜索了下，该产品系列中的监控产品我们是用全了。

兴奋，接手OV监控平台

流程管理中的变更管理其实蛮枯燥的，不仅如此，还占用很多时间——与不同的人争来吵去，我感觉我们的存在都是有一定问题的。幸好，刚刚接手了的OV监控平台可以花时间探索、研究。
每当人情绪极大波动的时候，找一件让自己专心致志的事情去做，就可以稳定情绪——而我，就选择了研究OV监控平台。

OVIS，简单好用的网络服务监控

遵循由简入繁的过程，OV监控平台中最简单的就是OVIS（OV Internet Service）系统了。虽然，没有OV Operations它可能无法告警，但依然无法掩盖它依旧是目前很不错的网络服务监控系统——当然，相对2014年来说，架构旧了点。

NNM，复杂的网络设备监控

再复杂点的，可能就是NNM（Network Node Manager）了。它在当时，功能相当强大，操作基本上是图形界面（当然，我们有部分功能是靠同事YY的脚本实现的），当然，这系统实质上也就3个人用过而已，可惜了这么一套功能强大的软件了。

OVO，主机监控，告警中心

说完前面两个，就必须说说OVO（OV Operations）了，如果说NNM是网络监控，可以将OVO看成是主机监控，OVO支持绝大多数操作系统，只要更新的话一般不会出现兼容性问题（更新=有购买售后）。并且，OVO当时就支持Server向Agent推送文件了，很多事情其实都可以从OVO的Server端统一管控了，你想做个全区的delete完全可以哈——只是这柄达摩克利斯之剑没发挥出其功效。当时觉得最有价值的是其内置了相当多的告警策略，都是HP总结了各种实施经验，以至于我们开启后管理员都不看了——他们都不知道什么意思，还得我们翻译。

OVPM，性能数据采集

OVPM（OV Performance Manager），一款不错的性能管理系统，主要功能就是借助OVO Agent进行简单性能数据采集，或者借助OVO Agent分发OVPM Agent进行更加详尽的性能数据采集。其实从今天的角度来看，OV监控平台是一个相当牛叉的监控平台，排除界面、Bug、价格和维护工作量外，其他都趋近完美了——Sorry，我把一些重要的因素都排除了:P

没有维保的苦恼

虽然是商业软件，但也存在或多或少的Bug，特别是当它遇到中国用户后。在使用一段时间后，纷繁复杂的情况使得软件中所隐藏的大量Bug纷纷爆发，特别上当我们按照惯例不购买维保的时候。

分布式，糟糕的尝试

随着机构规模的扩大，核心网络也随之扩大，为了解决外地网络问题导致大量无用告警的产生，分布式的项目被提上了日程。在经过小规模的测试和研究后，发现可以正常使用。随后，我们被要求只购买软件不购买服务，也就是说，我们自行进行分布式部署工作。于是，噩梦开始了。

心有余而力不足

在分布式架构部署完成之后，系统所存在的问题越来越多，网络上很少能够找到这些问题的一丝线索，加上我们无法得到有效的售后支持，这些问题就一丝一丝积攒着。我当时将HP支持论坛翻了个底朝天，但是通常解决方案就是——“请联系下HP售后支持解决”“哦，他们很快地解决了我的问题”。随后我联系发帖回帖的老外们，也都杳无音信，也是，他们都是04年、05年的帖子了——当时是2010年。

最终，选择了放手

没有售后支持，也没有网络上的帮助，软件本身存在Bug，作为管理员也无暇研究——一套软件系统到了这一步之后，我认为离崩溃也就不远了，再将问题汇总汇报给上级领导被视为无物后，心彻底凉了。恰好，有了一个机会，可以暂时的离开公司——权衡之下，只能对自己负责了。

令人无奈的问题

或许随着时间的流逝，领导的眼界也渐渐开阔了，看到阿里、腾讯公司那么多专家后，眼红了？
某一天，在汇报现有监控系统的隐患及问题后，领导突然理直气壮地问我一句话：“我们从04年开始使用OVO，为什么用了7年都没有个专家出来？”
我当时，无语了。

Nagios、Cacti，开源尝试

在北京的半年间，接触了一些开源的内容。回来后虽然工作内容发生了一定的变化，但只是暂时不做技术而已，空闲和忙碌交替着——由于最终还是要做回技术，所以当时有空就研究下开源监控相关的方面，Nagios、Cacti、Zenoss、Zabbix等等，基本上都接触过，但是由于使用便利性和周期的考虑，最终选择了Nagios和Cacit。

正文：
近半年的北京浮生，各种不同类型工作的交叉，确实对人的思维模式有着很大的影响。虽然基本上是三点一线（家、公司、支持方）的生活，但经历了很多，也思考了很多。虽然我们的项目最终没有成功，但是思路开阔了许多，相对于之前而言，解决问题也更加主动了。

触碰Zabbix

由于部门所能提供的资源有限，但是需求又是不断在增大着的，所以Nagios在投入使用半年后就遇到了一些问题，Cacti同样也是——主要集中在性能、功能、稳定这三个方面。最终，为满足领导的要求，再次对各种开源监控选型，最终选定了Zabbix。

进一步了解Zabbix

在经过了几个月的使用后，对Zabbix的了解也有一定的积累了——为什么用积累呢？因为后面一直有其他的工作要做，监控又成了副业……但是，临时搭出来的架构肯定不满足未来长久使用的要求，所以需要在不影响现有使用的情况下调整架构，优化系统，于是，开始对Zabbix进一步研究。

一个人的监控

记得在初中的时候，有一期《大众软件》吧，上面介绍了一个人，自己独立开发了一套以抗日为主题的，游戏方式类似炸弹人的国产游戏《地雷战》（多年前看到的，现在不记得了，杂志在八钢的家中），可惜游戏做好了，卖不出去——为什么呢，因为是他一个人开发出来的，从策划到设计到开发，因为是一个人……

惺惺相惜

就和武侠、战争片中上演的一样，英雄们总是惺惺相惜，现实中的高手们也是惺惺相惜，不论你在那一行那一档。运维的工作中也是一样，虽然工作再困难，但对你来说也没有什么，这只是挑战而已，难就难在没人能够理解你，所以，你或者换个环境，或者等待环境的到来。综合各种因素，我选择了等待。

关于重新造轮子的故事

我一直在想一个问题，国人是不是很喜欢早轮子呢？至少咱公司很喜欢早轮子。流行虚拟机了，就开始开发虚拟机，发现开发不了了，作罢。这几年流行云平台了，发现刚好有OpenStack和CloudStack，可以改吧改吧就上，于是乎……监控也是一样，前几年花了几十万自行开发监控系统，后续又花了不少钱——最后呢，方形的轮子大家凑合着用吧。

持续深入Zabbix

这一章，讲的就是是现状了。
说实在的，能完全把官方文档看完的人不多，我也只是跳着看，能去读Zabbix源码并了解其原理的人更少。估计大多数Zabbix用户都是网管或运维工程师吧，所以很崇拜 @超大杯摩卡星冰乐

番外篇：瞎扯下监控系统的选择

NB公司有研发队伍并且有大牛的，可以自己去研发监控系统。
土豪公司可以买产品，要买就买知名公司的产品，想专业就找外企，想炫就找国企。
没钱可以去折腾开源，让用户多提些需求，让领导少提些需求。