首页
下载应用
提交文章
关于我们
问卷:你怎么看自由微信?
🔥 热搜 🔥
1
上海
2
习近平
3
新疆
4
鄂州父女瓜
5
乌鲁木齐
6
疫情
7
H工口小学生赛高
8
习明泽
9
芊川一笑图包
10
印尼排华
分类
社会
娱乐
国际
人权
科技
经济
其它
首页
下载应用
提交文章
关于我们
问卷:你怎么看自由微信?
🔥
热搜
🔥
1
百度
2
今日热点
3
微信公众平台
4
贴吧
5
opgg
6
dnf私服
7
百度贴吧
8
知乎
9
dnf公益服
10
百度傻逼
分类
社会
娱乐
国际
人权
科技
经济
其它
白石洲拆迁后,那些上学奔波的孩子都去哪儿了?
一个医保局长之死
给宠物做保姆的中国留学生
本以为吴京大儿子叫“吴所谓”够随意了,听到二儿子名字,真服了
法院4.2元拍卖一瓶雪碧,限自提!被执行人回应:没有更多可供执行财产
生成图片,分享到微信朋友圈
查看原文
其他
怎样的监控,才真正说明系统有问题?
Original
58沈剑
架构师之路
2022-07-22
收录于合集
#自动化
5 个
#运维
7 个
#架构
78 个
监控不告警,系统就一定没有问题么?怎样的监控,才真正说明系统有问题?今天和大伙聊聊
多维度立体化监控
。
什么是多维度立体化监控?
不同公司或多或少有一些自动化监控手段,例如:
(1)http接口监控;
(2)log关键字监控;
(3)操作系统,进程,端口;
(4)http状态码;
(5)服务存活性;
(6)接口处理时间;
(7)RPC接口监控;
(8)用户层面监控;
如果只监控一个或少数几个维度:
(1)监控到异常时,基本确信系统出现了问题;
(2)反过来,没有监控到异常,不能确信系统没有问题;
例如:
(1)监控到操作系统CPU100%,系统大概率出现了问题,但CPU正常,并不能说明系统正常,例如tomcat挂了,CPU肯定是正常的,但操作系统监控却探测不到,于是需要进程,端口,存活性等其他监控予以辅助;
(2)进程,端口监控到异常,系统大概率出现了问题,但进程在运行,端口在监听,并不能说明系统正常,例如程序死锁,进程和端口是正常的,于是需要接口处理时间等其他监控予以辅助;
(3)接口处理时间监控到超时,系统大概率出现了问题,但接口处理时间不超时,并不能说明系统正常,例如数据库挂了,数据库连接拿不到,服务层每个接口都很快返回,并不超时;
这里的
观点
是:
单维度监控易漏报,多维度立体化监控才是监控平台的根本之道
。
前文介绍的两篇:
《
如何在12个小时,搞定http监控?
》
《
如何在12个小时,搞定日志监控?
》
在设计上都讲究通用
+
可扩展。
接下来介绍的四个维度的监控,在设计上也是看重“
通用
”“
非侵入性
”,即
被监控的站点和服务无需任何埋点,无需任何修改,被监控模块的负责人无需配合做任何事情
,就能全方位
cover
住。
维度一,如何进行操作系统,进程,端口监控?
监控需求
:
(1)系统的
网络
是否被打满,
磁盘
是否有空间,
CPU
是否繁忙,
内存
是否用完,
负载
值是否过高,
JVM
是否正常;
(2)服务进程是否运行;
(3)监听端口是否正常;
(4)机器间是否联通;
常见方案一
:zabbix
搞运维的都懂,不展开细聊了,聊多了怕被骂。
常见方案二
:shell
写一些非常简单的脚本,就能够获取到网络、磁盘、CPU、内存、load、JVM的信息,在配合一些阈值的配置,就能实现超出阈值告警的功能。
如果配合集群信息管理服务,通过ps, netstat, telnet等命令,也能快速实现进程,端口,连通性的简易监控。
实现要点
:
(1)重点考虑扩展性,可配置性,非侵入性;
(2)集群信息管理服务(或者,集群信息配置文件);
维度二,如何进行404
状态码监控?
监控需求
:监控http异常状态码。
监控方案
:nginx日志统一监控
如果实现了http接口统一监控,404监控的必要性并不是这么强,但毕竟实现简单,整一个通用的花不了多少时间。
在聊存活性监控,接口处理时间监控之前,多说几句系统架构,如果实现了框架与组件的统一,统一监控会省非常多的力气。
上图是一个典型的互联网分层架构图:
(1)最上游是APP和browser;
(2)
反向代理层
是nginx,统一http404状态码监控就实现在这一层;
(3)
web层
,假设自研了web-framework;
(4)
service层
,假设自研了service-framework,web层会通过RPC-client调用service;
(5)
数据层db
,假设自研了Daojia-DAO组件调用db;
(6)
缓存层cache
,假设自研了Daojia-KV组件调用cache;
D-DAO和D-KV两个组件并没有大伙想的复杂,初期只是简单的封装了一层而已。
维度三,如何进行服务存活性监控?
监控需求
:进程和端口的监控,只能保证进程在,端口在,但并不能确定服务是否能响应请求,需要确定服务“活着”。
监控方案
:ping-pong式监控,在站点框架,服务框架层面统一实现,提供keepalive接口:
(1)在框架层面就可以实现ping-pong接口;
(2)监控中心通过集群信息管理服务(或者是配置文件)获取集群类型(web/service),集群IP列表;
(3)监控中心统一往集群发送内置的ping-pong请求;
强调两点
:
(1)如果开源框架不提供ping-pong接口,可以二次开发(要慎重,任何开源框架的二次开发,都是大坑的开始);
(2)统一集群信息管理服务,或者,统一集群信息管理配置文件,真的很重要,是技术体系统一的基石;
维度四,如何进行接口执行时间监控?
监控需求
:
(1)http站点接口有没有超时;
(2)RPC服务接口有没有超时;
(3)db访问有没有超时;
(4)cache访问有没有超时;
(5)除了超时,还要监控同一个接口的执行时间有没有同比、环比的大幅度波动
,
例如:
一个接口平均响应时间是100ms,突然有一天增加到300ms,即使没有超时,也有理由怀疑接口出现了问题;
监控方案
:框架组件统一上报(如上图1,2,3,4)。
(1)在web-framework里,对所有http接口进行数据上报,可以上报
url,参数,执行时间
等核心数据;
(2)在service-framework里,对所有RPC接口进行数据上报,可以上报
接口,参数,执行时间
等核心数据;
(3)在DAO里,对所有数据库SQL访问进行数据上报,可以上报
sql,参数,执行时间
等核心数据;
(4)在KV-client里,对所有cache访问进行数据上报,可以上报
key,执行时间
等核心数据;
统一上报是思路,具体上报细节,是通过flume刷日志,还是storm/spark实时流处理,都可以。
总结
监控是一个技术活:
(1)监控平台的思路是
多维度立体化监控
;
(2)“统一操作系统、http404,服务存活性,接口处理时间”等四大类统一监控的设计核心是“
非侵入性
”,不需要任何人配合修改,就能实现诸多功能的技术平台,才是好技术平台;
(3)
统一集群信息管理服务,统一人员信息管理服务,统一告警策略服务
(或者配置文件),是统一技术体系的基石;
架构师之路-分享技术思路
思路比结论更重要,希望大家有收获。
调研
贵司的监控,涵盖了哪些方面?
您可能也对以下帖子感兴趣
{{{title}}}
文章有问题?点此查看未经处理的缓存