监控也是一个权衡的过程

  • 杨赛

2013 年 8 月 20 日

话题:DevOps

上周有朋友反馈说鸡汤太多了,今天来点干的。

Kevin Nilson 是 Just.me 公司的工程副总裁,也是硅谷 Java 用户组、硅谷 JavaScript 用户组和硅谷 GDG 的组织者,也是 Web 2.0 Fundamentals 一书的作者。Just.me 是一个社交类应用,有 iOS、Android 和 HTML5 版本,虽然用户数量目前还不是很多,不过因为其创始人也是 TechCrunch 的联合创始人,在影响力和产品理解方面都相当出众,所以也引起了不少关注。

在今年 7 月的 JavaOne 大会上,我跟 Kevin 聊了一些有关监控的话题,包括公共云平台下做监控需要注意什么,针对移动端如何做监控,监控工具是拿开源项目改还是自己做还是用商业方案等话题。其中一个话题是问他们监控哪些指标,Kevin 回复的相当详细,在这里跟大家分享一下。

首先,因为我们要监控的指标很多,所以你需要一个 dashboard,可以一眼看到所有指标的状态。监控的指标嘛,系统方面的肯定是最基础的,比如 CPU,那这个 dashboard 上肯定会有 CPU,负载状态,实例的健康度等等。

对我们来说,有一个指标是比较难监控到,但是又很重要的,就是活跃的请求数(active request)。想要了解每一个服务在一段时间内的活跃请求数具体有多少个,这是挺难的,但我认为也是最有价值的一个指标。当你的流量激增的时候,或者是当服务出现问题的时候,活跃请求数也会开始堆积,因为请求的处理时间变长了。对这个指标进行全局的查看是一个很有意思的事情,尤其是在 Java 当中为什么有固定数量线程池,就是因为有时候某个特定的请求(包括来自 API 的请求)可能会把整个服务都搞死,这是很恐怖的事情。所以,避免一个服务把整个站点搞死是很重要的事情。

还有很多服务,我不在乎它们跑的性能好不好。有的时候,你要区分考虑 get 和 post/put 的情况。当你往服务器发送信息的时候,这个过程往往是异步的,在后台的,用户并不知道这个动作实际上花了多长时间。而当用户从服务器取信息的时候,这个动作往往是需要用户等待的。所以,get 的速度指标会重要得多。

但反过来看,put 的动作意味着用户在把数据发给系统,这些从商业的角度而言又是比较重要的。在发送消息这个功能上,我们希望知道用户在什么时候发布消息,发布了多少消息,点了多少 like,发了多少评论,关注了多少人等等,我们需要知道这些数据。至于用户刷新页面刷了多少次,这个我们是不关注的。所以归根结底,这是一个权衡的过程。

然后,要说说我们用的、来自 Square 的 Cubism 工具。刚才我说要能够一眼看到所有的数据,那么 Cubism 所做的就是让数据叠加呈现,以颜色区分,你能够在一个页面上列出非常多的指标。

从运维监控的角度差不多是这样。至于商业的角度,主要还是看你的运营目标了。我们的 dashboard 从启动以来,上面的内容大概有 30% 都跟一开始不一样了。有些是我一开始以为我们会遇到问题的指标,但后来一直没遇到,所以移除了;有些是我们曾经遇到过问题,但后来解决掉了,所以也移除了。

现在剩下的指标,一个是 CPU——各个服务的 CPU 数据可以叠加显示,比如 MySQL CPU,EC2 服务器的 CPU,Lucene 索引服务的 CPU,Neo4j 的 CPU 等等,都可以垒起来。说到底,CPU 数据就是一个 0 到 100 之间的数值,如果没有超过 75%~80%,也没什么可担心的,所以一眼看过去就可以知道是否有问题。

然后是负载均衡,健康实例的数量,活跃请求的数量——这部分数据也是将不同服务的数据挤压到一起显示的,如果一个数值蹿升,则会触发警报。

还有 DynamoDB。这个我想多说两句。首先,DynamoDB 的支付方式实在是不怎么样,根本是违反云的精神的:你一次购买比如 100 个 DynamoDB 的读单元,无法自动扩展。如果你用到了 100 个,系统会停止给你返回结果,扔给你异常;如果你一个都没用到,也还是得为 100 个付钱。如果你不是全球性的站点,可能白天活跃晚上不活跃,你就要不停地去修改它的配置。这点实在让我很上火,因为我不得不老去盯着它有没有到达阀值。然后就是,DynamoDB 其实自己有配备 CloudWatch 监控窗口,但这个东西也够难用。我们的表很多,如果要用 CloudWatch 来看,光是开浏览器窗口都要开几十个,完全没有可用性。所以,我基于 Graphite 自己做了一个监控 DynamoDB 的工具,将来自各个表的数据整合到了一个窗口里面。

有一段时间,我们的 dashboard 上放了很多安全层面的监控数值:每一个需要通过 JAS 安全的请求,都要去看它用的时间。当时,我们的认证层有一些问题,一个请求过一遍安全层可能会花几秒钟的时间,这种情况下再去看其他性能指标就毫无意义了。后来这个问题修复了,我们就把这一项从 dashboard 移除了。

还有一项就是客服工单的开启数量。如果在一段时间内,忽然涌现出大量的客服工单,那很可能出现了你其他监控所没有发现的问题。所以我把这个数据也加进来。

最后,考虑到鼓舞士气的原因,我把一些市场数据也放进了 dashboard,比如装机量,注册用户数,整个系统处理消息的数量、回复的数量等等。这个主要是为了吸引团队成员的注意力,让他们有个理由多看看 dashboard。我们把 dashboard 放在办公室的大屏幕上,所有的团队成员都能看到。大家休息喝咖啡的时候,就会在屏幕下,谈论这些数据。这能勾起他们的好奇心,顺便引导他们去看上面的那些数据。

本日作者简介

杨赛(@lazycai),InfoQ 中文站编辑。到处串门的互联网信徒,相信规则的力量。

DevOps