微信号:yurii-says

介绍:我是这么以为的,当然你也可以那么以为

关于监控的几个基础问题

2017-05-03 08:47 余晟

前段时间看一个小伙伴的系统设计。他从系统的设计目标开始讲:第一,完成核心业务功能;第二,有监控;第三,出现问题能追溯…… 刚讲到这里就被我叫停了:真正投入实用的任何一个软件系统,监控和可追溯都应该是基础要求,这是常识,怎么好意思和“完成核心业务功能”列在一起?但是转念一想,或许对很多人来说,这也算不上“常识”,它们固然很重要,但学校里根本没教这些内容,怪不得大家。

况且,我自己也在监控上吃过很多的亏,深一脚浅一脚走过来,才会懂得这种“常识”。为了避免大家少走弯路,我来讲讲关于监控的几个基础问题吧。

监控是系统设计的必备要求

谈到监控,通常是广义的“监控”,它包含“监控”(monitor)和“报警”(Alert)。按照Effective Monitoring and Alerting这本书的解释,二者的定义如下:

监控:其作用是对既有系统维持认知,并衡量系统中的数据流转和状态改变。目的在于发现异常,在排障过程中提供帮助。

报警:报警系统应当具有这样的能力,能侦测到显著的状态变化对应的事件,并将事件告知操作和维护人员。

如果我们承认,软件工程不只是“开发软件的工程”,合格的软件开发人员必须关心软件运行情况,对软件的全生命周期负责,那么我们就应当承认,监控和报警是内嵌在软件开发中的,是系统设计的底限要求。运行再迅速、功能再强大的系统,没有监控和报警(以下简称监控),都是残缺的。

有很多开发人员也在一定程度上懂得监控的重要性,但他们并不重视,因为现成的监控系统很多,搭起来接入就好了。这样的态度是不对的,这样的设计是不合格的。按照上文的定义,合格的监控必须能持续提供对于既有系统运行状态的认知,而系统“运行状态”往往并不是现成监控系统、监控项所能覆盖的,因为“系统”并不能还原为一堆零件。比如说,如果你开发的是某种存储系统,单纯衡量CPU占用率、磁盘占用率、网络吞吐率,而忽略了每秒上传文件数、平均文件大小、平均存储事件、失败重试次数等等,那么你是无法建立对于存储“系统”的认知的。

所以,尽管有现成的监控系统可以帮一些忙,但更重要的是,在系统设计之初就问自己几个问题:如果要了解我的系统的运行状态,应当借助哪些指标?这些指标如何统计,以什么方式和频率统计?…… 如果开发人员不能很好地回答这些问题,最终开发出来的产品很可能会有问题,而且很可能是“莫名其妙”的问题,极难排查。

监控必须有足够存在感

我遇到过好几次这样的情况:系统上线了,监控也上线了,平时根本没有人看。甚至出现问题了,问对应人员平时运行情况是怎么样的,也拿不到满意答复,因为平时根本不关心。大家想的是:反正系统也上线了,也有监控了,就交给对应的人去关心就好了。结果监控系统成了僵尸,对真正应当关心监控信息的人来说,它没有什么存在感。

这样造成的直接后果是:排查问题的成本极高。因为设计数据统计和提供机制的与真正观察数据的是两拨人,而出现问题之后,又必须双方协同解决。毕竟,有产品意识的开发人员本来就少,有意愿又有能力把监控信息和监控系统设计到“傻瓜都能看懂”的开发人员就更稀少了。很多时候,监控系统里的数据不准还是其次,单纯一个不知所云的统计项就能让人完全抓瞎,根本谈不上有效监控、迅速定位。

之所以出现这种问题,通常都是因为监控系统缺乏存在感,平时没有人去关心。也就是说,光有监控系统是不够的,还应当让关心监控的人关心监控信息,给予足够的重视。

当然,如果应该关心的人有很好的职业素养,或者有上级明确的压力,这个问题不难解决,但很多时候这样的前提并不存在,应该怎么办?

其实已经有不少办法,最常见的就是变被动为主动,让监控主动来刷存在感。很多软件开发团队会专门安排几块屏幕放在大家都能看到的地方,上面实时显示系统的各种监控数据。这样的存在感会大大提升,总有人在路过或者放松的时候去留意它,有问题也会及时发现。即便“不是自己的问题”,也更愿意报告出来,提醒对应的人。比起那种“被动等待用户登录查看”的监控系统,这样的做法效果要好成千上万倍。

我有时还会推荐另一种“变被动为主动”的做法,就是让监控系统用邮件主动发监控的日报、周报。邮件这种形式有几个好处:第一,相比电话和短信,它对接收人的干扰比较小;第二,阅读时间比较自由,上线班路上花三五分钟看看邮件,就可以了解大致的情况;第三,既然是邮件,内容肯定会脱敏,避免在服务器端进行复杂的账号设置;第四,邮件天生是多副本的,查询历史数据的时候可以避免因为历史数据问题而扯皮。

当然,邮件通报监控信息也有天生的不足,因为邮件没法控制也没法追踪,很可能泄露秘密;同时,邮件里也无法进行复杂的查询。所以,邮件一般只用来做日常数据的报告。

监控系统缺乏存在感的另一个常见原因是,监控系统没有随被监控系统更新。被监控系统往往直接承担业务职能,所以总在不断变化的过程当中。如果监控系统不能随着被监控系统更新,要么成为无足轻重的路人甲,要么成为累赘最终被抛弃。总之,监控系统逐渐和被监控系统脱钩,失去存在感,被监控系统逐渐“解放”出来,回复到裸奔的状态。这种局面,相信任何人都不想看到。

监控必须系统化运作

“系统化运作”的第一重含义是,监控信息是分层次分渠道的。

我见到很多人拒斥监控系统的原因是:信息太多了,看不过来,重要信息反而被淹没。出现这种问题的原因通常就是监控信息没有分层,各种信息混杂在一起。结果要么是铺天盖地的信息让人一看就如坠五里雾中,要么是“狼来了”喊得太多导致真正出问题了反而没有人相信。

对正常的监控系统来说,信息一定是分层次分渠道。什么样级别的信息以什么方式传达给哪些人,这是在设计监控系统时应当仔细考虑的问题。具体的方案各种各样,总的宗旨是统一的:最有用的信息能以最短的路径、最简洁的方式提供给最需要的人,让他能迅速作出判断,识别问题。

“系统化运作”的第二重含义是,监控系统不容许开例外。

监控标准定出来之后,我见过各种解释:这里报错是误报,那里统计有问题…… 总的诉求都是希望在监控系统里开口子,让监控数据“看上去正常”,或者即便显示不正常,让大家知道“这是正常的”。

对正常的监控系统来说,这种诉求是很大的危害。既然有标准在,就不容许有那么多例外。否则,监控系统的复杂性和维护成本必然大大上升,因为新接触监控系统的人无法按公认普适的规则来理解各种数据。更重要的是,长此以往监控系统的可信度会受到严重影响,“既然你的数据不对有解释,那么我的数据不对也可以解释”,“既然你的出错可以说是误报,我的出错也不用那么准确”,这就是破窗理论的活生生的例子。

以上是关于监控系统的三个基础问题,最后我想说的是:监控系统与被监控系统是共生关系,应当同步演进和重构。理想情况下这是一个闭环,每出现一次事故,每发生一点故障,我们都需要反思整个发现、排障的流程,看看是否有漏掉了某些监控项,或者某些监控项还不够完善,以后持续验证这些改进是否有效…… 如果系统改进没有终点,监控系统的改进也没有终点。

推荐大家阅读O'Reilly的Effective Monitoring and Alerting(目前没有中文版)。我相信,即便你是“单纯的”开发人员,也会从中收到很多启示。

另:我之前写过《名不副实的“软件工程”》,引起很多争议和讨论,没读过的朋友可以参考。


优秀人才不缺工作机会,只缺适合自己的好机会。但是他们往往没有精力从海量机会中找到最适合的那个。

100offer 会对平台上的人才和企业进行严格筛选,让「最好的人才」和「最好的公司」相遇。

扫描下方二维码,注册 100offer,谈谈你对下一份工作的期待。一周内,收到 5-10 个满足你要求的好机会!



 
余晟以为 更多文章 侯局长不真实,高书记比较真实,但高老师教不出侯同学 我看范雨素 我的阅读之路【一】 赞赏对公众号有多重要? 别给你的“死工资”找借口
猜您喜欢 GitHub干货铺:JavaScript 测试框架Jasmine 【一周一讯】本周安全资讯回顾 iOSonRails:使用Access Token对访问进行控制 使用VS把ASP.NET 5的应用发布到Linux的Docker上 Go 性能优化技巧 5\/10