监控系统说三道四

监控系统说三道四

监控系统如今已经是互联网架构中的标配系统了,不同的是各家公司监控的覆盖面和颗粒度上的差异,关于运维那套监控系统ZIBBIX等不在本次说三道四范围内,最近一直在写监控系统的架子,就把看到的写过的总结下。

一、为什么监控

监控系统在传统的软件架构下并没有受到太大重视,因为可靠的硬件+软件的保障,做的最多的就是各种中间件的配置+代码优化,出了问题一拨IBM/MS的联系方式,现如今的移动互联网架构下的软件体系,面向的都是各种不可交付型送达,各种无状态、幂等等操作让客户端和服务器端各自都需要对信息进行一定容错处理,容错的背后,如何让系统知道什么时候在什么地方发生了什么事情,简单说就是一个log,可如果还想知道是谁的log,如何及时知道发生了log,如何根据log等级做到告警,如何对这段时间内的log内容进行统计,有了监控系统,这些个未知未知就变成已知了,有和没有的区别不在于得到了什么,而在于知道失去了什么。

二、监控什么

移动互联网架构中的监控究竟要监控哪些,每家公司侧重的都不一样,但大体上都大同小异,就是将整个系统中的服务进行应用画像,每个参与系统的应用在整个监控体系各自的名字、互相之间的关系和应用内+应用间的状态,这个和人的圈子是一样一样的,今天不舒服生病请假了,为了保障公司任务不停顿需要有一个交接人。

三、如何监控

监控在整个应用服务画像中原则上是一个完整的体系,但是在具体监控上还是分而治之的策略,应用状态本身的监控可以通过不断的询问获取,比如CPU/内存/硬盘/网络等,类似的还有mysql、redis、es、mongo等服务器的状态,应用处理的数据信息则是在处理数据时刻进行收集整理拿到,操作系统层面的监控可以通过运维手段获取,当然常规语言api也可以获取,服务应用可以通过client api调用获取,而数据信息的输入输出则需要对处理数据的单元进行监控,分布式环境下则需要对整个链路的输入输出进行监控,移动环境下的信息则需要将整个链路扩大到移动端+服务端。

对于需要对服务定制监控的系统来说,通常监控围绕链路+应用状态监控2个层面,今天简单总结下java环境下的链路监控的设计方式

四、如何设计

4.1 先假设一个现在用的比较多的移动互联网架构下的应用服务:

  • 系统类型
    • app (ios/andriod)
    • tomcat/jetty
    • jar (flat jar/jsw)
  • rpc服务
    • dubbo
    • grpc
    • thrift
  • http请求服务
    • okhttp
    • httpclient
    • restTemplate
  • db
    • mysql
    • es
    • mongodb

先写这么多吧,怕是摊大饼吃不完,如何设计应该也是所有programer相对比较关心的内容


4.3 监控流程

关于监控流程中的技术选型,借用2张图仅作参考,一般都这个套路

图片

图片

4.3.1 植入

植入是我瞎编的词,aop时候一直用的是织入

java监控和信息收集主要有以下几种,不正确请指正

  1. Agent形式,通常是用字节码修改技术+java.lang.instrument等方式,可以做到无侵入监控,参考pinpoint,grays,BTrace

Agent形式使用java -javaagent:agent.jar -jar xxx.jar方式运行,具体请google java.lang.instrument

javaagent 通常使用字节码等技术,常用asm、javasist等框架执行,在性能检测工具中使用较多,jdk6中对java.lang.instrument的功能增强 java attach api可以做到运行前、运行中对java应用进行监控检测

aspectJ是国内很多公司常用的织入方式,同样使用的也是javaagent方式,AspectJ的Load Time Weaving机制,需要配置 -javaagent: [path to aspectj-weaver.jar] 。

打开aspectj-weaver.jar,可以看到META-INF/MANIFEST里定义了 Premain-Class: org.aspectj.weaver.loadtime.Agent

  1. 过滤器、拦截器、aop等配置化方式收集,配置化植入,可以无需修改代码,参考zipkin+brave

和agent不一样的是,这种方式是典型的分而治之的策略,使用被监控方的方法来监控对方,这种方式应该是平常开发过程中最常用的方式。

  1. 代码埋点植入,需要添加植入代码收集,参考cat、cat2

具体使用参考cat,开源了很久,没有过多研究,不好发表评论

开发难度系数逐级递减,接入系统难度系数逐级递增,我想说的是监控并不是任何时候越细越好,凡事都是一把双刃剑,监控毕竟和业务系统是强绑定在一起运行的系统,对性能度的影响是最难以把握的。同时监控系统本身的健壮度也是第一考量的要素。

4.3.2 收集

收集是整个监控系统最大头的一块,不同类型的应用收集的方式、信息内容不尽相同,收集的内容不是拍脑袋出来的,一切都基于收集的信息在后面落到应用中的目的,收集只收集有需要的信息,否则数据仓库变成了垃圾仓库了,数据的关联性+有序性是关键,这里google最具代表性的Dapper论文讲的太详细,参考这里的中文翻译,这也是绝大部分监控 ppt 常用的素材地: http://bigbully.github.io/Dapper-translation/

图片

图片

在收集系统中有很多可以统一收集的层,同时还有很多需要收集的埋点,可以在某一个面上进行收集的理解为层,必须在某个点上收集的称为埋点,两者的关系需要根据实际场景中进行组合还是拆分,一般链路上的收集包括层+埋点,而孤立或者几个有关系的点则需要单独埋点进行特别关照。

4.3.3 传输

传输是对收集模块信息pipline中的虚拟概念,如何理解完全根据采用的架构图设计,一般主要使用如下几个方式:

  • log方式,直接入盘,则传输人是log框架,比如logback log4j等
  • kafka生产者,传输人是kafka
  • http请求,传输人则是http请求框架,okhttp httpclient等
  • 其他存储client,直接落入存储 mongodb,es,hbase等,结束
4.3.4 接收

接收是相对传输来讲的,除直接落地外,其他的都需要整合接收功能对信息统一+持久化,具体情况根据信息量+延迟参考:

  • log方式,使用flumeng或者logstash等日志文件读取框架二次传输
  • kafka消费者,接收log并持久化,有些时候这里可能还会接Storm进行实时分析
  • http服务器,服务器统一收集后再选择二次传输
4.3.5 落地

落地是对收集的信息统一管理并持久化起来,通常主要考虑的是存储的无限扩展性、高可用性,基于这个原则,常用的有

  • Elasticsearch 直接集成搜索分析功能
  • Hbase 常规选择
  • Mongodb 太多
  • Cassandra 国内使用较少,3.0之后用的应该还不错
  • Hadoop 不多说,批量干活的说

4.4 告警

告警系统是监控系统中最重要的一环,信息的落地如何对业务进行反馈完善是告警系统价值所在,没错,将损失降低到最低。

基础的告警功能就是简单的匹配,比大小等算法,当发生的事情和预期一致或者不一致时,发出警告(邮件、短信、微信等),和自动化测试的思路比较相似

高级的告警功能,(拍脑袋的时候到了),各种自监控,自反馈,智能分析反正没有做不到只有想不到了,太遥远,看来做好基础告警功能才是王道。

未开启讨论功能请往这走,😁:

欢迎star github: https://github.com/xuminwlt/j360-trace

oschina博客: https://my.oschina.net/smartsales/blog