前段时间某甲方大人(富得流油)说他们日常运维人员天天忙的不行,每天穿梭于好几套性能监控系统,问我们能不能给想想办法,在不铲掉现有几套性能监控系统的情况下,让他们不用切换系统就能搞定日常运维需求。这个需求从项目经理那传到了产品经理那、又从产品经理那传到研发经理那、然后就传到我这,我记得我说有(做)点(不)麻(到)烦(阿)呢;再然后合同就下来了。
两个字,干活。
先说下甲方大人的需求和痛点,甲方大人说平日的系统运维工作主要围绕应用、主机、数据库和业务四个方面。
(1)应用发布平台是IBM的WebSphere Application Server(简称WAS),应用的性能监控基于WAS自带监控模块;
(2)主机监控基于IBM Tivoli Monitoring System,业务监控则通过分析应用日志的方式实现。
(3)数据库监控依赖一个古老的oracle性能监控工具;
(4)应用日志需要登陆到AIX业务机器上查看;
“每当出现一个问题,先登陆was看下业务进程性能趋势,再登陆Tivoli查看主机性能趋势,然后登陆数据库监控查看数据库性能趋势,再然后登陆AIX主机查看日志。一套下来肚子就饿了,到食堂发现好吃的饭菜已经被别人抢光了,希望你们能帮我们改善改善伙食“。嗯,听上去影响蛮大的,不过他们怎么知道我烧菜的手艺的,上周末做的清蒸鲈鱼味道还不错...
四个字,干活干活。
在了解了甲方大人的需求和痛点后,经过一番苦思冥想,设计了上面的看上去有点复杂的架构图,超过20个字怕甲方大人看不懂。大道至简,借鉴老子的一段话附和一下这张图,
“人法地、地法天、天法道、道法自然”,
老子
用了十三个字,将天、地、人乃至整个宇宙的生命
规律
精辟涵括、阐述出来。
菜谱准备好了,小葱拌豆腐,开始下锅。
数据采集上,针对WAS、Tivoli、Oracle和AIX应用主机的采集需求,需要coding了(没有什么需求是一坨代码解决不了的,如果有那就两坨):
(2)开发一个Tivoli数据收集器,又花掉一个晚上,Tivoli支持Soap方式拉取新能数据,我不会告诉你可以用一个CURL拉取所有主机性能所有数据的,想知道的留言处扣666;
(3)开发一个Oracle数据库性能采集器,还好elastic 大佬开源了beats
https://github.com/elastic/beats,坑爹的是竟然不支持oracle,莫非oracle大佬的开发人员都休眠了么;花了两个晚上捣鼓捣鼓,支持个tps、qps、物理读、逻辑度、吞吐量还是可以的,小算一下支持200多个指标吧,oracle采集beat依赖oracle
感兴趣的猴子们可以试试走一遍上面的过程,一个上午+两个晚上+几杯咖啡的事情,咖啡给大家推荐一款来自的马来半岛的OWL,俗名猫头鹰,非常适合晚上睁大眼睛看屏幕用,香甜可口纵享丝滑。。。
坚持看到这里就是真爱了,贴上一张系统架构图,图中左方是数据采集层,easymanager是公司自研的自动部署神器(不用想了,没有开源),右边是数据展示端,把应用、主机、数据库、日志数据统一展示在一张大屏上,废话不说了,上菜!
(谢幕要另起两行)
验收会上,项目验收会上,
甲方大人面无表情,我们的项目经理滔滔不绝黄河之水,
项目经理:“was 进程性能数据、主机性能数据和数据库数性能据数据趋势图,高业务量对应高负载、高性能消耗和高数据库读写,关联估算出业务量和性能数据之间的比例关系,实现关联分析;同时通过业务闲时异常性能数据趋势(如异常持续高负载,异常持续高内存消耗,异常持续高数据库读写)情况定位应用程序的故障,辅助故障定位及时对故障应用程序进行处理。在业务高峰期,持续的业务高峰和持续的性能负载趋势会触发告警,及时对性能故障和业务高峰压力进行预警,辅助故障预警和决策...“。
甲方大人:“哦,吃饭“。