多维度立体化监控,才是真的监控

前文介绍了通用+可扩展的http监控平台与log监控平台的架构:

通用+可扩展http监控平台/框架

通用+可扩展log监控平台/框架

结果,评论里各种冷嘲热讽。

监控这个topic本来有很多细节可以聊,既然大伙公司都做得比较完善,后续就不纠细节了,聊聊方向上的思考,架构上的设计。今天和大伙聊聊多维度立体化监控。

一、什么是多维度立体化监控

不同公司或多或少有一些自动化监控手段,除了前文提到的:

  • http接口监控
  • log关键字监控

还有很多维度的监控:

  • 操作系统,进程,端口
  • http状态码
  • 服务存活性
  • 接口处理时间
  • RPC接口监控
  • 用户层面监控

如果只监控一个或少数几个维度:

  • 监控到异常时,基本确信系统出现了问题
  • 反过来,没有监控到异常,不能确信系统没有问题

例如:

  • 监控到操作系统CPU100%,系统大概率出现了问题,但CPU正常,并不能说明系统正常,例如tomcat挂了,CPU肯定是正常的,但操作系统监控却探测不到,于是需要进程,端口,存活性等其他监控予以辅助
  • 进程,端口监控到异常,系统大概率出现了问题,但进程在运行,端口在监听,并不能说明系统正常,例如程序死锁,进程和端口是正常的,于是需要接口处理时间等其他监控予以辅助
  • 接口处理时间监控到超时,系统大概率出现了问题,但接口处理时间不超时,并不能说明系统正常,例如数据库挂了,数据库连接拿不到,服务层每个接口都很快返回,并不超时

这里的观点是:单维度监控易漏报,多维度立体化监控才是监控平台的根本之道

前文介绍的http接口监控,log关键字监控,在设计上都讲究通用+可扩展,接下来介绍的四个维度的监控,在设计上也是看重“通用”“非侵入性”,即被监控的站点和服务无需任何埋点,无需任何修改,被监控模块的负责人无需配合做任何事情,就能全方位cover住。

画外音:如果有一天你有机会负责框架,组件,基础服务,技术平台等部门,你就会明白“非侵入性”有多重要了,在公司推一个技术产品太困难了。

二、操作系统,进程,端口监控

监控需求

  • 系统的网络是否被打满,磁盘是否有空间,CPU是否繁忙,内存是否用完,负载值是否过高,JVM是否正常
  • 服务进程是否运行
  • 监听端口是否正常
  • 机器间是否联通

常见方案一:zabbix

搞运维的都懂,不展开细聊了,聊多了怕被骂。

常见方案二:shell

写一些非常简单的脚本,就能够获取到网络、磁盘、CPU、内存、load、JVM的信息,在配合一些阈值的配置,就能实现超出阈值告警的功能。

如果配合集群信息管理服务,通过ps, netstat, telnet等命令,也能快速实现进程,端口,连通性的简易监控。

实现要点

  • 重点考虑扩展性,可配置性,非侵入性
  • 集群信息管理服务(如果没有服务,有集群信息配置文件也行)

关于集群信息管理服务,详见《集群信息管理,架构设计中最容易遗漏的一环》。

三、404状态码监控

监控需求:监控http异常状态码。

监控方案:nginx日志统一监控

如果实现了http接口统一监控,404监控的必要性并不是这么强,但毕竟实现简单,整一个通用的花不了多少时间。

在聊存活性监控,接口处理时间监控之前,多说几句系统架构,如果实现了框架与组件的统一,统一监控会省非常多的力气。

上图是一个典型的互联网分层架构图:

  • 最上游是APP和browser
  • 反向代理层是nginx,统一http404状态码监控就实现在这一层
  • web层,假设自研了web-framework
  • service层,假设自研了service-framework,web层会通过RPC-client调用service
  • 数据层db,假设自研了Daojia-DAO组件调用db
  • 缓存层cache,假设自研了Daojia-KV组件调用cache

D-DAO和D-KV两个组件并没有大伙想的复杂,初期只是简单的封装了一层而已,具体的实现方案在《框架组件,究竟要不要自研?》一文中有深入的讨论。

四、服务存活性监控

监控需求:进程和端口的监控,只能保证进程在,端口在,但并不能确定服务是否能响应请求,需要确定服务“活着”。

监控方案:ping-pong式监控,在站点框架,服务框架层面统一实现,提供keepalive接口:

  • 在框架层面就可以实现ping-pong接口
  • 监控中心通过集群信息管理服务(或者是配置文件)获取集群类型(web/service),集群IP列表
  • 监控中心统一往集群发送内置的ping-pong请求

强调两点

  • 如果开源框架不提供ping-pong接口,可以二次开发(要慎重,任何开源框架的二次开发,都是大坑的开始)
  • 统一集群信息管理服务,或者,统一集群信息管理配置文件,真的很重要,是技术体系统一的基石

关于集群信息管理服务,详见《集群信息管理,架构设计中最容易遗漏的一环》。

五、接口执行时间监控

监控需求

  • http站点接口有没有超时
  • RPC服务接口有没有超时
  • db访问有没有超时
  • cache访问有没有超时
  • 除了超时,还要监控同一个接口的执行时间有没有同比、环比的大幅度波动

例如:一个接口平均响应时间是100ms,突然有一天增加到300ms,即使没有超时,也有理由怀疑接口出现了问题

监控方案:框架组件统一上报(如上图1,2,3,4)

  • 在web-framework里,对所有http接口进行数据上报,可以上报url,参数,执行时间等核心数据
  • 在service-framework里,对所有RPC接口进行数据上报,可以上报接口,参数,执行时间等核心数据
  • 在DAO里,对所有数据库SQL访问进行数据上报,可以上报sql,参数,执行时间等核心数据
  • 早KV-client里,对所有cache访问进行数据上报,可以上报key,执行时间等核心数据

统一上报是思路,具体上报细节,是通过flume刷日志,还是storm/spark实时流处理,都可以。

六、总结

监控是一个技术活,并不是大家评论里说的“搭一个ELK就搞定了,何必这么麻烦”:

  • 监控平台的思路是多维度立体化监控
  • “统一操作系统、http404,服务存活性,接口处理时间”等四大类统一监控的设计核心是“非侵入性”,不需要任何人配合修改,就能实现诸多功能的技术平台,才是好技术平台
  • 统一集群信息管理服务,统一人员信息管理服务,统一告警策略服务(或者配置文件),是统一技术体系的基石

原文发布于微信公众号 - 架构师之路(road5858)

原文发表时间:2018-02-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏

基于JMS的数据交换既数据互操作平台的解决方案

为解决应用系统间数据和信息的互通、互用,建立一个通用的、分布式的数据集成平台,用以解决异构数据平台数据交流和沟通的问题。

5704
来自专栏北京马哥教育

手把手教你无代码基础实现Linux运维管理平台

老早之前就想做一个运维管理平台的项目了,但是一直没沉下来去做,上半年的时候毕设选择了这个课题,想着逼自己一把,不管做出来的怎么样,先把它搞起来..... dj...

3525
来自专栏架构师之路

小小的IP,大大的耦合,你痛过吗?

什么是耦合? 耦合,是架构中,本来不相干的代码、模块、服务、系统因为某些原因联系在一起,各自独立性差,影响则相互影响,变动则相互变动的一种架构状态。 感官上,...

4676
来自专栏开源优测

有那么几张图给大家看看

771
来自专栏猿人谷

三种Linux服务器监控技术的对比

本文介绍三种Linux服务器监控技术的优缺点,其中有SNMP代理(客户端)方式、SSH方式、安装私有代理(客户端)方式等内容。 Linux系统的强大的功能和绚丽...

2427
来自专栏Linyb极客之路

系统架构之高可用服务层设计

众所周知,服务层主要用来处理网站业务逻辑的,是大型业务网站的核心。比如下面三个业务系统就是典型的服务层,提供基础服务功能的聚合

1272
来自专栏匠心独运的博客

过来人的经验,谈谈一致性处理方案—分布式事务(DTS)

传统事务是使用数据库自身的事务属性(ACID),而数据库自身的事务属性是局限于当前实例,不能实现跨库。而对于大型分布式/微服务集群系统中,不仅存在着跨库的事务,...

4144
来自专栏BeJavaGod

RabbitMQ 一二事(4) - 路由模式介绍

路由模式其实和订阅模式差不多,只不过交换机的类型不同而已 ? 路由模式可以用下图来表示,比订阅模式多了一个key,举个栗子就是根据不同的人群来订阅公众号,来收取...

3415

Apache CloudStack系统VM架构选择

最近我和一些人讨论了为什么现在有一个32位或64位系统虚拟机和CloudStack 4.3 (一个云计算平台)的选项。我提供了一个答案,并且回复了一些邮件列表...

2087
来自专栏网络产品使用分享

【腾讯云的1001种玩法】利用 Auto Scaling 节省30%成本

公有云提供了很多免费的高级功能,很多中小用户以为自己用不上。实际上稍微研究一下,就能享受很多便利和节省不少成本。 本方案就是利用弹性伸缩(auto-scalin...

9410

扫码关注云+社区

领取腾讯云代金券