庖丁解牛之监控系统(一)

写在前面

       我从事运维自动化相关的工作，也已经8年了。当初刚开始做的时候，运维开发(devops)这词还不火。很少人知道。国内对运维的理解，也就是机房、服务器、苦逼的7*24小时值班。甚至当时还流传着段子，招运维要人高马大，扛得动服务器。

      很幸运的主导了两个一线互联网公司的公司级的运维自动化。这俩公司的服务器，都是几十万台级的，IDC都是几十个。很多事情都是摸索着来。一路走来也形成了一些对运维自动化的理解。第一家公司好容易做的七七八八的时候，到第二家实施发现原有的很多理解都被打烂了重新来。但这种经历反而凝练了一些经验。我个人性格原因，不喜欢到外面去讲。偶尔实在没法推辞过去的，也诚惶诚恐的准备，到最后发现很多干货还是没办法一言以蔽之。最后留在外面的都是一些只言片语，不成系统，更不敢说能指导多少。

      终于下定决心要把我个人的一些理解，通过系列文章来写一写。文笔有限，可能写的不尽人意。也欢迎大家加入运维开发讨论交流群来交流，群号 365534424 

     废话少说，直接上文。

庖丁解监控(一)

 我始终认为监控对于运维来说，犹如眼睛对人来说一样重要。不管说的多么高大上，运维工作里面很大一部分还是响应型的工作。来自于架构调整、服务变更或者来自于监控。说监控是整个运维或者服务生命周期里面最重要的一环都不为过。从事前发现，预警或者故障报警，到事后提供监控现场供回溯追查，监控系统贯穿了运维整个环节。怎么才能有一副好视力，今天我们就来稍微谈谈。

  正因为监控系统如此重要和通用，所以业内最成熟、最多的产品也是监控系统。商用的、开源的监控系统比比皆是。也有一些很优秀的开源系统应用很广泛。比如Zabbix、cacti、nagios、ganglia等。对于使用开源系统，还是自己开发(相信看这个文章的，应该都不会有购买监控系统的打算)，是使用者自己决定的。业务和团队规模都不足够的时候，直接拿来主义，开源的系统能解决基本问题，性价比高。业务如果后期发展的好，规模快速扩大，复杂度迅速增加的情况下，开源系统就难以为继了。表现在时效性、扩展性、二次开发、支持的服务规模(或者叫系统容量)、良好的权限控制等各方面。

  从上面几点来看，一个监控系统需要具备的是数据采集、扩展性、告警管理、高可用、历史数据存储与展示、权限管理等几个方面。

监控本质上就是对被监控对象的状态进行判定。这个监控对象可以是服务器、交换机，也可以是一个几千台服务器的集群，还可以是带宽、CPU利用率，甚至深入到服务内部，监控服务内部的进程、线程、cache命中率等。

监控对象多种多样，既有实体的，也有虚拟的。 被监控对象的状态进行判定，这句话里面有三个要素。被监控对象、状态、判定。所以监控系统要能够适配足够多的监控对象类型、收集并能转换为可衡量的状态值，才能支持下一步的判定动作。例如，一台服务器上的nginx服务的连接数。服务器上的nginx服务，就是被监控的对象；连接数就是被监控对象的指标，那么状态呢？我们可以定义为，超过1万就是不正常，否则是正常。

   从这个角度做框，我们来看看监控系统的核心指标都有哪些。首先是能监控的对象范围要越多越好(当然你可以说小而精的也挺美。但维护多套监控系统也是代价)。也就是数据采集，能采集的渠道、支持的方式、采集的指标越多越好。

   未完待续

本文出自 “Reboot运维开发” 博客，转载请与作者联系！