怎样的监控,才真正说明系统有问题?

开发 开发工具
监控不告警,系统就一定没有问题么?怎样的监控,才真正说明系统有问题?今天和大伙聊聊多维度立体化监控。

监控不告警,系统就一定没有问题么?怎样的监控,才真正说明系统有问题?今天和大伙聊聊多维度立体化监控。

[[355642]]

什么是多维度立体化监控?

不同公司或多或少有一些自动化监控手段,例如:

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

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

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

例如:

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

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

接下来介绍的四个维度的监控,在设计上也是看重“通用”“非侵入性”,即被监控的站点和服务无需任何埋点,无需任何修改,被监控模块的负责人无需配合做任何事情,就能全方位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实时流处理,都可以。

总结

监控是一个技术活:

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

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

 

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2019-05-08 09:43:00

Elasticsear LuceneJava

2015-06-09 15:28:14

编程能力编程

2010-03-02 14:46:03

Android核心系统

2018-03-15 08:36:07

2018-07-19 19:04:10

Python编程语言

2018-09-17 08:36:59

机房监控配电

2017-05-10 08:39:34

装机线缆机箱

2018-08-15 14:18:34

算法AI机器学习

2017-12-07 16:13:18

程序员编程代码

2019-08-01 07:40:01

物联网测试物联网IOT

2014-06-09 10:51:59

2015-12-01 10:54:49

安全产品采购供应商选择信息安全官

2011-03-24 08:56:23

nagios监控

2013-07-17 10:02:54

工程师创新

2017-12-19 17:36:05

策划

2009-10-19 15:01:22

机房监控摩卡

2017-11-12 21:12:34

HPC

2015-09-02 11:44:39

视频云华为

2012-10-18 15:07:12

创业用户创业者

2016-11-04 20:27:38

点赞
收藏

51CTO技术栈公众号