文章目录
  1. 1. 关于监控的一点点思考
    1. 1.1. 一、监控的目的
    2. 1.2. 二、工具选型的重要性
    3. 1.3. 三、监控软件实现的特征
    4. 1.4. 四、How to do ?

关于监控的一点点思考

大家都在谈监控,也一直在做监控,监控也是每个系统管理员的必修课。不管是采用开源软件实现,或是在此基础上进行二次研发,还是完全自主研发一套。其实现的目的都相同,运用的手法也大相径庭。目前大多数公司都会选择采用开源监控软件来实现自己的需求,因为开源世界里这些软件越来越多且功能越来越完善。在这些开源软件中使用最多的数:Nagios,Zabbix。并不是说Ganglia、Zenoss、Cacti等并不好用,而是热度不够高。笔者最近在使用监控软件去实现一些功能时,有感而法,想讲讲自己多年来对监控的一点点思考。或许本篇谈的一无事处,你就当饭后茶点吧。

说明
本篇同时发表于CSDN《程序员》杂志2013年第12月刊。

在谈之前,先问问读者朋友监控的目的到底是什么?

一、监控的目的

对于大多数人而言,都是在遇到故障或处理问题后,才发现监控并没有添加,要不就是说监控没有添加到位,再有甚者说监控并没有报出来。作为领导,是并不关心这些,他们更多的是注重结果。这事就这么发生了。这个时候很多人也会跳出来说,为什么非要结果导向?我这么辛苦努力处理故障,我有错吗?

事实上都没有错,结果导向没有什么问题,处理故障也很辛苦,而做为一线工程师,乃至一名优秀的工程师更多的是需要思考:

  • 为什么?
  • 为什么我没有提前添加呢?
  • 为什么我之前就没有考虑到呢?
  • 是因为我的问题,还是团队协作的问题?如果是因为你的问题,那你应该好好反思了;如果是因为协作的问题,研发或其他人在交付给你时,就是一团浆糊,那么你是否尝试做过改善?没有改善,你是否想到过反馈等?;反馈了也没有结果,这说明你做得还不够。不断地总结,才能提高。

为此:不管在什么状态,你是否已经想明白监控的目的是什么呢?

我尝试把这个问题抛给群里,结果没有多少人回答,或者说没有概括性回答。其实监控的目的可以简单地用一句话来概括:描述一个完整生命周期的事物,当出现异常时汇报,以保证生命周期的完整性。

二、工具选型的重要性

当我们知道要做什么的时候,就需要一把利刃来帮助我们实现。选择好一把利器能让我们事半功倍。我们可以从最为热门的Zabbix和Nagios中做出选择。对于两者的特色功能个人总结如下:

Zabbix特色功能:

  1. 分布式监控,原生态
  2. 自动化功能,自动发现,自动注册,自动添加模板,自动添加分组
  3. 自定义监控,支持变量,支持low level discovery
  4. 触发器,多重判断机制,多重自定义
  5. 支持多种监控方式
  6. 丰富的API,方便用户定制
  7. 与Puppet部署结合,可以说如鱼得水

Nagios特色功能:

  1. 框架化
  2. 插件化,并提供丰富的插件
  3. 灵活的自定义

就应用场景而言,笔者认为Zabbix提供了丰富的报表功能,而Nagios需要通过插件来完成且图表不太好看。因此Zabbix适合一站式,而Nagios适合自主式。

为此在挑选监控工具时,需要根据自己的应用场景进选择,但需要明确的是选择并利用好工具只是手段,并不是目的。

那么,监控软件它要实现的特征都有什么呢?

三、监控软件实现的特征

监控软件都应该满足且具备如下特征,我才认为它是一个合格的,而更多的是需要我们系统管理员来实现,而不是一味的依赖于工具。

  1. 良好的扩展性和弹性,能应对突发网络中断
  2. 自动化,部署与数据同步自动化
  3. 模块与智能关联,定义各组件功能等,并能自动建立服务间的关系
  4. 传感和汇聚模块,收集指标数据,并进行数据的转换、处理、汇总等
  5. 状态与存储,跟踪事件的变化自动根据相关信息分析,并存储相关数据
  6. 通知与可视化,根据状态发送报警消息,并通过仪表板提供可视化界面
  7. 丰富的API,提供各项功能及多种接口,可通过接口进行数据定义
  8. 业务形态的结合,与业务的生命周期完美的结合

再次问读者朋友:采用什么样的工具来解决一个或多个问题真的那么重要吗?

答案是肯定的。一个好的工具能让你的工作事半功倍,但它不是万能的。带着目的去思考,应该如何去实现,且能具备一个监控软件应该具备的特征。那么你将会明白,应该将更多的时间花在实现上,利用工具实现你的需求达到你的目的,而不是将时间花在工具。
为此当我们知道工具能实现什么功能后,深入挖掘它,马上根据业务特征进行生命周期性监控,以达到我们的目的;根据业务及产品形态进行分解,这个分解的过程是很痛苦的,但结果一定是可观的。

在分解时,需要多换位思考,如果我是产品经理或研发人员,我需要什么样的数据来支持我呢?

  1. 产品经理需要产品的数据报表,定期将数据汇报给上层
  2. 研发人员需要调试代码,在出现bug时能及时发现

多从别人的角度思考问题,相信监控给我们的工作带来的不只是无修止的报警,而是更好的数据报告。

要做到这些,我们到底应该如何去做?

四、How to do ?

在谈到监控的目的是,或许还有读者没有理解。从系统管理员的角度来看,也可以简单概括为:

  1. 提供可靠的数据,用以推论系统的承载瓶颈
  2. 可以从多个维度分析用户与系统压力的关系
  3. 快速有效的实时监控,并按规则做出预警
  4. 有详细的故障分析,用以分析历史数据并总结经验

简单吧?要是这么简单就好了。我们以以一个产品上线开始为一个生命周期,来看下监控具体需要做什么:

  1. 基础监控(给产品提供孵化室)
    • 网络监控(网络延迟与丢包、包大小、坏包流量、端口、路由表等)
    • 服务器监控(CPU、MEM、DISK、IO、等)
    • 应用监控(吞吐、服务状态、响应时间等)
    • 数据监控(死锁、错误日志、性能等)
    • 硬件监控(硬件错误、硬件故障、风扇、温度等)
    • 日志监控(错误日志,状态日志等)
  2. 产品监控(保证产品孵化成功)
    • 测试环境(产品稳定性、产品研发调试等)
    • 生产环境(并发度、容错、异常等)
  3. 良好的报表(发现规律,解决问题)
    • 通过趋势来发现规律(提前找出规律,规避潜在故障)
    • 业务形态的完整展示(给相关部门提供有力的数据保障)
  4. 报警策略(减少误报,多报)
    • 不同时段
    • 不同人群
    • 不同业务
    • 合并报警

有些人可能会说了:好简单啊,也不是那么复杂嘛。是的,其实监控并没有我们想像中的那么复杂,监控一定不能脱离业务,在实施时根据业务的整个周期所需进行监控。同时也需要根据产品、业务、环境等不同而随时变化。世界的变化尚有轨迹和规律可寻,日常生活中我们也将这些规律奉为圭臬,道理很简单,因为我们遵照此规律可以获得好处或利益,违反它则要付出代价。何况监控呢?

一名优秀的工程师经常做的就是根据环境做出调整,同时一次又一次地熟悉业务、熟悉开发、熟悉产品。再根据历史经验,一些教训进行总结,但一定要规避能加而未加的知识。其次还需要多测试,以验证监控的各种稳定性与风险。做完这些,或许你就可以高枕无优了。

这里只是聊一些我关于监控的思考,而做为监控的同胞兄弟:报警,却没有多谈。因为报警有着不同的策略,有些是很暴力的,等哪天想写了,就跟大伙再次聊聊报警的一些思考吧。

文章目录
  1. 1. 关于监控的一点点思考
    1. 1.1. 一、监控的目的
    2. 1.2. 二、工具选型的重要性
    3. 1.3. 三、监控软件实现的特征
    4. 1.4. 四、How to do ?