中小企业监控体系构建_知识分享【面试总结】

　　大名鼎鼎的中国运维社区的狼首赵瞬东相信你们都略有耳闻，江湖人称赵班长，曾在武警某部负责指挥自动化的架构和运维工做，2008年退役后一直从事互联网运维工做。曾带团队负责国内某食品电商的运维工做，同时带领团队建立了本身的运维社区，讲本身多年经验传递给众多学者、运维人员，同时他也是即将出版的《saltstack入门与实践》做者之一。

　　他的一篇博文对我颇有启发，想要成功就是向有经验的人学习因此我也在按照他的脚步再爬。废话很少说请看正文之——详解企业监控体系构建:

【内容借鉴思想！面试案例真实！】　　

　　在我以前的公司，招聘面试中，个人老大必问的一个问题就是“大家以前公司的监控体系是怎么作的？你认为怎么作效果比较好？”

　　常常获得这样相似的答案：“咱们公司用的Nagios、Cacti作监控，或者说咱们公司用Zabbix作监控”，再继续追问每每获得的也是如何使用这些工具的细节的回答。

　　这样的回答当然没错，但却反映出来运维人员常常会被工具迷惑双眼，从而忘记了最初的出发点。然而今天我被问到了。我答的并很差，特此总结：

1. 肯定目标、统一思想

　　咱们直接跳过什么是监控和监控的重要性等大段描述，先仔细的想想，监控的目标是什么？

　　每一个人的答案都不一样，个人回答是：终极目标就是为了保证业务的持续和稳定运行。如此偏激的回答就是让读者从如今开始要站在业务的角度的开始规划监控体系，而不是某个技术范畴。

　　注意：本文不涉及性能测试、性能优化中的监控，全部文字的出发点都是平常运维监控。

　　在开始以前，咱们仍是先统一下认识：要监控一个对象，须要掌握哪些东西呢？

　　监控对象的理解：要监控的对象你是否了解呢？好比CPU究竟是如何工做的？

　　监控对象的指标：咱们要监控这个东西的什么属性？好比CPU的CPU使用率、负载、上下文切换。

　　肯定报警基准线：怎么样才算是故障，要报警呢？好比CPU的负载到底多少算高？

　　若是上述的条件不知足，那就先不要开始实施监控了，由于等作完了，你会发现，然并卵？

二、监控实时过程

 

系统监控是监控体系的基础，系统监控主要的对象有：

• CPU

• Memory

• IO

 

CPU：关于CPU，有3个重要的概念：上下文切换（context switchs），运行队列（Run queue）和使用率（utilization）。

这也是咱们CPU监控的三个重点。一般状况下，每一个处理器的运行队列要小于等于3，CPU 利用率中user/system比例维持在70/30，上下文切换要根据系统繁忙程度来综合考量。

经常使用的监控工具备：top vmstat mpstat

 

内存：Linux虚拟内存是一个庞大的东东，一般咱们须要监控内存的使用率、SWAP使用率、同时能够经过内存的使用率曲线来发现某些服务的内存溢出等。可是，很巧的是阿里云并无SWAP。此处咱们也作一下记录

监控工具备：free vmstat

 

IO：IO分为磁盘IO和网络IO。除了在作性能调优咱们要监控更详细的数据外，那么平常监控，只关注磁盘使用率、io wait便可，网络也是监控网卡流量便可。工具备iostat iotop iftop。

 

TCP监控：在不少状况下有必要监控TCP的状态，可使用netstat或者ss来获取全部的TCP链接，来展示11种不一样的TCP链接状态的数量，能够在大并发中及时发现TCP的相关故障。

 

其它的系统监控还有运行的进程数、登录用户、Open File等。

 

应用服务监控也是监控体系中比较重要的内容，例如：

• Apache：Apache提供了mod_status和mod_info模块用来输出Apache的状态，各类grep和awk搞定。

• Nginx：一样有状态模块，编译的时候加上—with-http_stub_status_module，而后就可使用stub_status on来开启了。

• Memcached：使用nc给memcached发送了一个stats命令就获取到了全部想要的信息。

• Redis：使用nc给redis发送了一个info命令就获取到了redis的相关状态。

• JVM：使用jmconsole，或者jmx就能够进行远程监控。

三、引入Zabbix

固然，以上想要监控的内容，zabbix均可以实现

• 硬件监控：Zabbix IPMI Interface

• 系统监控：Zabbix Agent Interface

• Java监控：Zabbix JMX Interface

• 网络设备监控：Zabbix SNMP Interface

• 应用服务监控：Zabbix Agent UserParameter

• MySQL数据库监控：percona-monitoring-plulgins

• URL监控：Zabbix Web 监控

　　使用Zabbix Proxy能够实现多机房的分布式监控，对于告警通知：邮件、微信、短信、钉钉等，均可以与Zabbix快速的集成，网上有不少此类文档。

　　同时，针对某些能够进行直接处理的报警，Zabbix能够触发Action来轻松帮你实现，故障的自动处理。好比阿里的自我修复机制，一台服务器宕机根据自身毁坏度进行自我修复自主上线。这个须要强大的开发能力，也能够经过shell脚本进行判断，此处不作过多解释。

四、流量分析

　　万事俱备只欠东风，基本监控都已经搭建完成，此时若是你的领导问，我们的PV是多少啊？此时你该如何应答？

　　netstat -ant | awk '/^tcp/{b[$NF]++}END{for(i in b)print i,b[i]}'

　　首先想到的是把访问日志拿出来各类awk而后sort一下，可是，难道就没有作这些统计和分析的工具吗？答案是有的。

　　google分析、百度统计、站长工具等等一堆统计的东西，只须要在页面嵌入一个js便可。

　　可是呢？这个数据始终是在对方那里，并且功能定制起来也不方便，因而google帮助了他，一个叫作piwik的开源项目映入眼帘。

　　网站流量分析对于运维人员来讲，更是一门必须掌握的知识了。好比对于一家电商公司来讲，经过对订单来源的统计和分析，能够了解咱们在某个网站上的广告投入有没有收到预期的效果。能够区分不一样地区的访问人数、甚至商品交易额等。

　　并且，流量分析是运维向运营拓展的必经之路，做为一名运维工程师颇有必要掌握公司站点的各类访问详情。

五、网络监控

　　网络监控是咱们构建监控平台是必需要考虑的，尤为是针对有多个机房的场景，各个机房之间的网络状态，机房和全国各地的网络状态都是咱们须要重点关注的对象，那么如何掌握这些状态信息呢？咱们须要借助于网络监控工具Smokeping。

　　Smokeping 是rrdtool的做者Tobi Oetiker的做品，是用Perl写的，主要是监视网络性能，www 服务器性能，dns查询性能等，使用rrdtool绘图，并且支持分布式，直接从多个agent进行数据的汇总。

　　同时，因为本身监控点比较少，还能够借助不少商业的监控工具，好比监控宝、基调、博瑞等。同时这些服务提供商还能够帮助你监控CDN的状态。

六、安全监控

虽然iptables能帮助完成四层的安全防御，可是针对七层的Web层面怎么办呢？

那你说能够用Nginx + Lua编写了一个WAF，而后把相关的日志记录到了Elasticsearch中，经过kibana能够图形化的展现不一样的攻击类型的统计。

八、业务监控

那你的领导又问你，我们10点的时候总订单是多少，每分钟平均订单有多少？这时候你又蒙了。（根据不一样的公司不一样的需求）

没有业务指标监控的监控平台是一个不完善的监控平台，一般在咱们作监控系统中，必须将咱们重要的业务指标进行监控，并设置阈值进行告警通知。

好比每分钟的订单、每分钟注册、日活用户、短信使用量等重要的业务指标均可以加入到Zabbix上。

注：因为业务监控图表，涉及到隐私的数据太多，就不截图了。

九、日志监控

一般状况下，系统会产生系统日志、应用程序会有应用的访问日志、错误日志，服务有运行日志等，可使用ELK来进行日志监控。

对于日志来讲，最多见的需求就是收集、存储、查询、展现，开源社区正好有相对应的开源项目：

• logstash（收集）

• elasticsearch（存储+搜索）

• kibana（展现）

咱们将这三个组合起来的技术称之为ELK Stack，因此说ELK Stack指的是Elasticsearch、Logstash、Kibana技术栈的结合。

若是收集了错误日志，那么若是部署更新有异常出现，能够当即在kibana上看到。固然也可使用Zabbix来进行错误日志的过滤来进行告警。

十、自动化

　　通过努力，终于从监控菜鸟到头脑中有一个相对完整的监控体系的逆袭，可是在大规模的环境中，若是没法作到自动化监控，那么手动添加监控不只仅是一个恐怖的工做，并且也没法保证完整性。

　　自动化的方案有不少，一般有主动和被动不一样的形式，这里相对Zabbix来讲。

主动形式：

　　好比使用Zabbix的自动发现，主动的对全网进行扫描，而后自动添加相关的监控服务器和引用监控模板。

被动形式：

　　也可使用Zabbix API进行被动的监控的添加。好比以CMDB为核心，若是检测到某服务器增长了Nginx服务，那么自动调用Zabbix API添加上Nginx的监控模板。

　　真正想作到更完整的监控体系，目前的开源软件，确实没法很好的知足，有条件的公司都开始本身开发本身的监控系统，好比小米开源的Open-Falcon。

　　也有比较好的开源的监控框架如Sensu等，再加上influxdb grafana能够用来定制符合本身企业的监控平台。

 

 

到面试结束

　　该结束了，由于我不管怎么努力增长，仍是以为总有漏下的，打死我也说不出来那么多。

　　监控的话题还有不少不少，好比还有和运维相关的页面性能监控（页面资源数量、DNS解析时间、首屏时间、加载最慢的资源、产生阻塞的JS等）、代码监控、与运维无关的舆论监控等，先这么多吧！

　　好的，咱们是从面试开始引入的监控的话题，那么就从面试结束吧！下次再遇到相似的面试题，我相信读者内心必定有了本身的答案，这里就不在详述，一个相对完善的运维监控体系是否已经在你脑海中造成了呢？

 

FAQ：

故障自动处理有没有相关的思路？

　　不一样业务形态、不一样架构、不一样服务可能采用的方式都不一样，这个没有一个固定的东西分享。能够参考以前腾讯蓝鲸的分享，他们实现了故障自愈的功能。

运维须要懂业务吗？

　　我我的的观点是懂业务能让运维走的更远，运维服务的对象不必定是其它部门，为何不能是终端用户呢？

　　能够站在终端用户的视角来作运维，好比有用户反映访问慢，为何慢，是架构的缘由，Nginx配置的缘由，仍是数据库的缘由。

　　不要等着领导来安排，运维能带来的价值是须要运维本身作出来的，思想有多远，运维就能走多远！

　　那么监控在这里发挥的做用就是：让数听说话！

 

若是你是一名运维工程师，动手干吧，监控会是一个不断完善的工程，这就是运维（运营）和项目的本质区别。